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6.MI-1 General Technical Requirements 

The General Technical Requirements shall be applicable to all RFCS equipment, 

unless more specific subsystem specifications are provided in the subsequent 

Sections. 

6.111-1.1 Physical and Materials Requirements 

(a) All equipment shall be designed for use in the transit industry, with specific 
attention to ergonomics, reliability, efficiency, and safety for passengers, 
operators, maintenance personnel and other system users. 

(b) Equipment furnished under these specifications shall be the latest model in 
current production, as offered to commercial trade, and shall conform to 
quality workmanship standards and use materials consistent with transit 
industry requirements. 

(c) The Contractor shall represent that all equipment offered under these 
specifications is new. 

(d) Used, shopworn, demonstrator, prototype, re-manufactured, reconditioned, or 
discontinued models are not acceptable. 

(e) All external screws, nuts, and locking washers shall be stainless steel or an 
approved alternate non-corrosive material; no self-tapping screws shall be 
used unless specifically approved. 

(f) All parts shall be made of corrosive resistant material, such as plastic, 
stainless steel, anodized aluminum or brass. 

(g) Equipment shall be designed to prevent unauthorized access, and to facilitate 
authorized access. 

1.1.1 ADA Requirements 

All equipment and devices shall comply with the requirements of 49 CFR 
Parts 27, 37, and 30 as amended through the date of this Contract, 
implementing the provisions of the Americans with Disabilities Act 
(ADA) of 1990, as amended. 

1.1.2 Modular Design 

(a) The Contractor shall utilize modular design throughout. 

(b) Standard, commercially available components shall be used 
wherever possible. 
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(c) All functionally identical modules, assemblies and components 
shall be fully interchangeable between all equipment acquired 
under this contract. 

(d) All modules and assemblies shall be connected using standardized 
durable, positive-locking, indexed quick disconnect fasteners. 

1.1.3 Upgradeability 

All equipment shall be modularly upgradeable so that it does not need to 
be replaced in its entirety to increase memory capacity, to upgrade 
processing perfonnance, to reconfigure I/O options, or to maintain 
compatibility with ISO 14443 standards as they are developed and 
adopted. 

1.1.4 Vandalism 

Contractor shall include provisions to protect all equipment and 
components from common vandalism and physical abuse by individuals 
wielding portions of their body, or wooden or metallic implements. 

6.111-1.2 Software Requirements 

1.2.1 General Software Requirements 

(a) All software shall be written in a common and well-known modern 
high-level, highly structured language. 

(b) All software shall be the current version in production at the time 
of Phase II installation. Software versions to be approved by the 
Contract Administrator. 

(c) All software shall contain version control numbers. 

(d) Features shall be provided to identify the software version on each 
device, and verify that it is the correct or most recent version for 
that device. 

(e) All use of assembly/machine language shall be submitted for 
review and approval during the design review. 

(f) Software shall be organized in a modular, table-driven fashion to 
the extent possible. 

(g) Adjustable, Agency specific and customization parameters shall 
not be hard-coded onto the source-code; they shall be user- 
modifiable. 
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(h) Application software (both user and system) shall be portable, i.e. 
the source code shall be transferable to other computers using the 
same operating system without any modifications. 

(i) The application software shall be scaleable to newer, higher 
performance hardware or operating systems. 

(j) The application software design shall be developed using 
structured software development methods (to be approved by the 
Contract Administrator), and shall be submitted for the design 
review. 

(k) The system shall contain all supporting software required to 
implement, operate, modify, and maintain all graphics displays and 
interactive screens. 

(l) Passwords shall not be displayed on Video Display Units. 

(m) All software shall be self-diagnostic. 

(n) All source code shall include application and individual module 
descriptions. 

(o) All user and system interfaces shall have online help features. 

(p) The operating system should be standardized for all systems and 
Year 2000 operability must be provided. 

1.2.2 National Architecture Conformance 

(a) The RFCS shall demonstrate conformance with the Intelligent 
Transportation Systems (ITS) National Architecture as defined in 
6.III-1.2.2(b). Information on the National Architecture can be 
found at http://www.its.dot.gov/aconform/aconform.htm 

(b) The Contractor shall prepare and submit for review and approval a 
National Architecture Conformance Plan (CDRL 30), including at 
a minimum the following: 

i. Elements of the RFCS affected 

ii. Applicable standards 

iii. Description of approach to achieving ITS conformance 

iv. Description of confonnity to the Central Puget Sound ITS 
Regional Architecture. Reference documents are available 
at: 

http://www.psrc.org/datapubs/pubs/reg arch.htm 

and 
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http://www.psrc.org/proiects/its/documents/guidance.pdf 

The RFCS project is included in the Regional Architecture. 

v. Approach to achieving the requirements of “Federal Transit 
Administration National ITS Architecture Policy on Transit 
Projects, Section VI, Project Implementation”. This 
document is available online at 
http://www.its.dot.gov/aconform/Policv 2.htm 

vi. Approach to incorporating the emerging Transit 
Communication Interface Profiles (TCIP). It is the 
Agencies desire to develop component and subsystem 
interfaces that are open, defined, and compliant with the 
emerging TCIP standards. At a minimum, fare transaction 
data elements downloaded to the DACS shall utilize TCIP 
where possible, and the FTP shall be able to accept location 
data in TCIP format. Information on TCIP can be found at 
http://www.ite.org/standards/tcip.asp 

(c) As part of the National Architecture Conformance Plan, the 

Contractor shall identify the applicability of, and compatibility 
with, the emerging Dedicated Short Range Communications 
(DSRC) standard. For current information regarding this standard 
contact: 

Mr. William Jones 

Technical Director 

US DOT, ITS Joint Program Office 

400 Seventh Street SW 

Room 3416, Mailstop HOIT-1 

Washington, DC 20590 

Tel: 202-366-2128 

email: william.s.jones@fhwa.dot.gov 

6.111-1.3 System Security 

The Contractor shall develop a comprehensive System Security Plan (CDRL 31) 
which identifies the system elements which require protection, and identifies 
mechanisms, procedures and processes to counter security threats to those elements. 

(a) The System Security Plan shall describe the intended functionality 
for each of the system security elements, shall identify security 
threats, and shall describe procedures, functions and systems for 
detecting and mitigating those threats. 

(b) The System Security Plan shall identify system users, and describe 
rules that govern how those users will have access to system data, 
resources and processes. 
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(c) The System Security Plan shall identify methods of detecting 
security breaches regardless of whether there is a detectable 
change in the perfonnance of the system. All security breach 
detection’s shall be confidential, and accessible only to users with 
appropriate access permission. 

(d) Security provisions for Agency-supplied and Contractor-supplied 
communications networks shall be described. 

(e) The System Security Plan shall be submitted with the design 
documentation. 

(f) The System Security Plan shall be approved by the Contract 
Administrator. 

(g) The Contractor shall implement system security services to 
achieve the approved System Security Plan. 

(h) The Contractor shall be responsible for providing security for 
Contractor-supplied RFCS equipment and facilities, and security 
recommendations for Agency-supplied RFCS facilities equipment 
regardless of existing security facilities and systems provided by 
the Agencies or others. 

1.3.1 System Elements and Protection 

(a) At a minimum, the system security shall protect the following 
types of RFC system elements: 

i. Equipment and facilities installed in public locations. 

ii. Equipment and facilities installed in Contractor-owned or 
operated locations. 

iii. Equipment and facilities installed in Agency-owned 
facilities. 

iv. Software source and compiled code. 

v. Data communications and interfaces. 

vi. Other communications and interfaces as might be required 
for the work. 

vii. System data. 

(b) The Contractor shall coordinate with each Agency to develop 
system security elements and procedures that function with 
existing Agency firewalls and shall identify for each Agency any 
recommended measures to secure Agency-supplied 
communications networks. 
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1.3.2 System Security General Services 

At a minimum, the system security shall provide the following types of 
services: 

(a) All RFC systems, subsystems and devices shall allow only 
authorized users access. 

(b) The system shall provide access control based on the establishment 
of groups, users and roles: 

i. Groups, users and roles shall be assigned during system 
implementation as directed by the Contract Administrator. 

ii. A minimum of ten (10) groups shall be provided for. 

iii. Each user shall have a unique identification and password. 

iv. The system shall include flexibility to add new groups, 
roles and users, redefine groups and roles, and reassign 
access permission as part of nonnal system operations. 
Access permission shall be assigned by the System 
Administrator. 

(c) All system access shall be recorded. 

(d) The system security shall include features to limit the propagation 
of access permission. 

(e) For all data transactions, the system security shall include 
authentication features to verify that all claimed source, recipient 
or user identities are correct and valid. 

(f) All data transactions shall include non-repudiation features to 
verify message content, and resolve claims that data was not 
correctly originated or received by a certain user. 

1.3.2.1 Protection from Unauthorized Access 

As a minimum, the system security shall provide protection from 
intentional or accidental unauthorized access including the following: 

(a) Physical access to equipment or facilities. 

(b) Access to Contractor provided computing systems and software. 

(c) Access to Agency computing systems and software. 

(d) Access to funds, accounts and funds-related data, owned and non- 
owned. 
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(e) 

Destruction, removal, corruption or modification of data or other 
resources. 

(f) 

Interruption of service, including as a minimum component, 
device, subsystem or system operation, and system 
communications. 

(g) 

Access to any system stored or created data. 

1.3.2.2 Data Integrity 

The system security shall provide features to maintain data integrity, 
including as a minimum: 

(a) 

Error checking shall be provided. 

(b) 

Data transferred from a device or system shall not be purged or 
written over until a successful transfer is confirmed. 

(c) 

Features shall be provided to ensure that all transaction and 
system-created files are uniquely identified, and that no files are 
lost or missed during data transfer. Verification features shall be 
provided to confirm that there have been no losses of data at any 
point in the system. 

(d) 

Verification features shall be provided to confirm that there have 
been no unauthorized changes to or destruction of data. 

(e) 

Features shall be provided to automatically detect, correct and 
prevent the propagation of invalid or erroneous data throughout the 
system. 

1.3.2.3 Data Confidentiality 

(a) 

The following types of confidential data shall be maintained in the 
system: 

i. Transaction data related to an individual Agency, employer 
or other system user 

ii. Personal information on cardholders 

iii. Revenue and other system-confidential data. 

(b) 

The system security shall include the following minimum data 
confidentiality features: 

i. Features to prevent access to personal or other confidential 

data by unauthorized users 
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ii. Features to prevent unauthorized association of a user 
identity with user-specific activities 

iii. Recording and audit of actions taken by that user. 

1.3.3 Security Mechanisms 

The Contractor shall identify and document the specific mechanisms to be 
used to implement the system security services in accordance with the 
plan. At a minimum, the following information shall be provided. 

(a) For non-cryptographic mechanisms: 

i. Identification of the security devices for equipment and 
personnel. 

ii. Description of access control for applications. 

iii. Description of the secure routes for the transmission of data 
and resources. 

iv. Participants certification process. 

v. Trusted hardware and software components. 

vi. Security access process as granted by defined roles. 

(b) For cryptographic mechanisms: 

i. Description of encryption, including symmetric (private 
key) and/or asymmetric (public key), for confidentiality. 

ii. Description of the hash functions for message integrity 
checks. 

iii. Description of the digital signatures for authentication and 
non-repudiation. 

(c) For cryptographic support mechanisms of keys: 

i. Generation, distribution and archiving. 

ii. Directories and certification. 

iii. Recovery/escrow. 

1.3.4 Alarms 

(a) As a minimum, the system shall provide the following alarms, and 
shall notify the appropriate users in the event an alann is 
triggered: 

i. Detection of invalid or erroneous data. 

ii. Detection of a security breach. 

iii. Detection of a device or system fault. 
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To the extent the Contractor is unable to access an Agency- 
supplied communications network in a manner necessary to 
directly monitor and detect security breaches within said network, 
the Contractor shall be restricted to information collected by the 
SNMP server within the Agency (as per section 6.II-8.2.1(d)). The 
Contractor shall immediately notify the subject Agency of any 
problems thereby detected. 

(b) All alarms and SNMP traps accessible to Contractor shall be 
recorded and stored in a database, along with a history of 
corrective actions. 

(c) Users with associated privileges shall be able to manually override 
alarms. 

(d) Alarms that are manually overridden shall reactivate at a user- 
defined period until corrective action is taken and the alarm 
cleared. 

6.MI-1.4 Data Backup and Recovery 

(a) The Contractor shall prepare a comprehensive data backup and recovery plan. 
(CDRL5) 

(b) The Contractor shall provide a data backup system for data archiving and 
recovery. The data backup system shall include capabilities for an Agency to 
back up data through network-wide backup. 

(c) It shall be possible to recover and transfer data files in the event of a primary 
data storage failure through a secondary standardized PC interface such as an 
RS 232 port. 

(d) In the event of a primary data storage failure and/or backup data storage 
battery failure, an indication on the display shall alert the clearinghouse 
system. 

(e) Correct password entry shall automatically enable RFCS device to download 
the transaction data to the back-up device. 

i. Neither the RFCS equipment nor the backup device shall capture 
the correct password. 

ii. Unsuccessful attempts to enter the password shall be logged. 

iii. The log shall contain detailed information, including the date, 
time, location, RFCS equipment number, and erroneous password. 

(f) An alternate process for initiating data extraction and/or alternate means of 
removing data records may be provided which shall be subject to Contract 
Administrator review and approval. 
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(g) The Contractor shall provide a detailed description of alternate process for 

initiating data extraction and/or alternate means of removing data records and 
the technical details necessary for Contract Administrator evaluation. 

6.MI-1.5 System Reliability and Availability Requirements 

1.5.1 Reliability Requirements 

Reliability is defined as Mean Transactions Between Failures (MTBF) 
that a specific type of RFCS equipment in service is performing. 
Transactions are defined as completed load or payment transactions. 

Figure III-1.1 provides a summary of the reliability requirements for 
relevant RFCS equipment. 

(a) In a low transaction volume environment, reliability (MTBF) 
shall be calculated as follows: 

i. Operating time for each type of equipment shall be 
summed and the result divided by the number of chargeable 
failures. FTPs shall be considered operational unless 
reported non-operational. 

ii. A low transaction volume environment is defined as any 
FTP processing zero (0) up to 250 transactions per day. 

(b) In a high transaction environment, reliability shall be calculated 
as follows: 

i. All transactions (full patron cycle) for each type of 
equipment shall be summed and the result divided by the 
number of chargeable failures. 

ii. A high transaction volume environment is defined as any 
FTP processing 251 and higher transactions per day. 


Figure 111-1.1 

EQUIPMENT RELIABILITY SECTION REFERENCES 


Equipment 

Section Reference 

Fare Card 

6.111-2.3.1 


6.MI-2.3.2 

Fare Transaction Processor (all configurations) 

6.111-3.3.2 

Driver Display Unit 

6.111-6.3 

Wireless Data On-Off Load System 

6.111-7.3 

TVM Integration 

6.111-10.3 

Customer Service Terminal 

6.MI-11.3 

Data Collection System 

6.111-12.3 

Back Office Client Computer 

6.111-13.5 


1.5.2 Availability 
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The Contractor shall prepare a System Availability Measurement Plan 
(CDRL 39). Availability is defined as the probability that a device, a 
subsystem of a device, or a data server or computer system is operating. 
The base equation presented in Figure III-1.2 shall be used to calculate 
availability. The four primary components of availability are: 

(a) Required operating hours = time the equipment is required to be 
available to conduct transactions or other operational activities. 

(b) Scheduled maintenance hours (as applicable) = time required for 
predefined scheduled equipment and system maintenance and 
servicing activities. 

(c) Required revenue servicing hours = time required for revenue 
servicing activities such as exchanging money containers, and 
replenishing card and receipt stock. 

(d) System out-of-service hours = time that the relevant system is not 
available to conduct transactions within the predefined scheduled 
operating window. 


Figure 111-1.2 

AVAILABILITY BASE EQUATION 

Availability = Effective operating hours - System out-of-service hours 

Effective operating hours 

where: effective operating hours = [required operating hours - (scheduled 
maintenance hours + required revenue servicing hours)]. 

1.5.3 Failure Review Team 

A Failure Review Team (FRT) shall be established to evaluate which 
failures are chargeable against the Contractor’s reliability requirements. 
The FRT shall be comprised of, as a minimum, one member from the 
Agencies or designated Agency representative, and as a minimum one 
member from the Contractor. Responsible parties within this team will 
initially attempt to settle any disputes. The Contract Administrator will 
give its opinion on any disputes that remain unsettled after a period of two 
weeks after the FRT meets to evaluate a specific failure. In the event the 
Contractor does not agree with the Contract Administrator, it may resolve 
the issue pursuant to the disputes procedure set out in Section 3.1-72, 
Conflict Resolution. 

1.5.4 Corrective Action 

(a) In the event that the devices do not meet the reliability 

requirements, the Contractor shall identify and implement remedial 
action, including, as necessary, modification of the equipment, on- 


Contract 229944 


6.MI-11 


April 29, 2003 




General Technical Requirements 


Division III 


site engineering services, on-site technical services, or other 
related action at no cost to the Agencies. 

(b) In the event the installed equipment does not meet these 
requirements, and remedial action requires the Contractor to take 
an individual device (other than depot maintenance devices) out of 
service for more than 12 hours to implement equipment 
modifications or replacement, the Contractor shall arrange for a 
supplemental device at that location as necessary, so there is no 
reduction in service while remediation is taking place. 

(c) The Contractor shall provide a replacement device within 24 hours 
of notification. 

6.111-1.6 Electrical Requirements 

1.6.1 Equipment Power Supply 

All Equipment installed in Agency or third party facilities with the 

exception of any on-board equipment shall operate from a nominal line 

voltage of 120 VAC, within voltage tolerances of + 10% to -10%, and a 

frequency range of 57 Hz to 63 Hz without equipment damage. 

1.6.2 Electrical Protection and Grounding 

(a) The Contractor shall provide equipment that meets applicable 
specifications and criteria of the Underwriters Laboratories 
Incorporated (UL), National Electrical Code (NEC), and the 
regulations of the State of Washington and local jurisdictions. 

(b) The Contractor shall be responsible for securing Underwriters 
Laboratories and other electrical certifications, and shall be 
responsible for any costs associated with the certification process 
and/or inspections. 

(c) All device enclosures shall contain an easily accessible master 
circuit breaker that will remove power from the equipment when 
tripped. Circuit breakers shall clearly indicate when they have 
been tripped. 

(d) All enclosures, chassis, assemblies, panels, switch boxes, tenninal 
boxes, and similar enclosures or structures shall be grounded. 

(e) Protective grounding shall be provided to ensure that all exposed 
metal equipment and metal fixtures are connected to a common 
ground point in the electrical cabinet. 
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1.6.3 Wiring 

(a) Conductors that have the potential of operating at 50 volts or more 
shall not be bundled with any other lower voltage conductors. 

(b) Wire dress shall allow sufficient slack for three (3) additional “re¬ 
terminations” without excess tension. 

(c) Wire splices are not permitted. 

(d) Wire and cable ties shall not be so tight as to cause indentation and 
damage to the insulation. 

(e) Adhesive-mounted bases shall not be used to support wire ties or 
cable supports. 

(f) All conductors within each enclosure shall be installed free from 
metal edges, bolt heads, and other sharp or interfering points. 

(g) All conductors providing connections between components shall 
be provided with strain-relief, and be clear of moving objects that 
could damage either the conductor or the object. 

(h) All terminations and cables must be clearly indexed, labeled and 
schematically identifiable. All wire labels shall be non-metallic 
and shall resist standard lubricants and cleaning solvents. 

(i) When components must be connected to each other through 
individual wires, the wiring shall be incorporated into a wiring 
“harness,” where each branch of each circuit can be separated from 
others for troubleshooting. 

(j) All components interconnected through individual wires contained 
within a “harness” shall be disconnected from the harness by 
disconnecting a durable, positive-locking, indexed quick 
disconnect fastener. 

1.6.4 Printed Circuit (PC) Boards 

(a) Where possible, all components shall be connected to the main 
logic circuitry by plugging into slots on a printed circuit 
“backbone.” 

(b) All PC boards shall be interchangeable with the same printed 
circuit board on other devices purchased under this contract. 

(c) All PC boards that have through holes shall be through hole 
plated. 
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(d) All PC boards shall be at least NEMA Grade FR-4, epoxy glass, 
green with weave appearance, and shall have a heat/mechanical 
load limit of 5. The 5 indicates the “peel strength” of the laminate 
(pounds per inch of width needed to peel off a strip of copper 
cladding at an elevated temperature, NEMA publication LI 1- 
1971). The copper laminate shall be firmly affixed to the PC board 
and shall not blister or peel when heated with a soldering iron. 

(e) The component side of the board shall be silk-screen printed with 
component references and other identifying information which 
corresponds to PC board schematics to aid in repair and 
troubleshooting. 

(f) Sufficient clearance between components shall be provided to 
allow for component testing, removal, and replacement. 

(g) Identifiable test points for circuit troubleshooting shall be provided 
on modules and PC boards. 

(h) All markings on PC boards shall be in English. 

(i) All PC boards shall have a unique, pennanent serial number that 
cannot be altered during nonnal repair. 

(j) Fuses or built-in protection shall be provided on all driver circuits 
to prevent damage to those transistors or other devices that drive 
relays, solenoids, print heads, and motors. The fuses shall be 
easily replaceable without damaging the PC board. 

(k) All PC boards shall be “indexed” to prevent insertion in the wrong 
slot or the wrong direction. 

(l) All PC boards shall contain the manufacturer catalog or reference 
number, version level and serial number for tracking purposes. All 
such identifiers shall be pennanently affixed to the board. 

(m) PC boards in on-board equipment shall employ pin/socket 
connectors, and shall not use printed card edge fingers. 

1.6.5 Relays 

(a) The contact tips of any relays shall not be placed in parallel for the 
purpose of carrying a current load at or above the manufacturer's 
contact tip rating. 

(b) Bifurcated contacts shall be used in low-voltage applications 
whenever necessary due to dry contact switching requirements. 
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(c) 

All relays shall be installed such that they are fully accessible for 
testing, removal and replacement. 


(d) 

All relays shall be socketed with captive spring retainers to hold 
relays in place. 

1.6.6 

Switches 


(a) 

Poles of switches shall not be placed in parallel to carry current at 
or in excess of manufacturer's contact pole rating. 


(b) 

Switches shall be provided with a “keying” feature such that, after 
installation, the body of the switch will be constrained from 
mechanical rotation. 

1.6.7 

Equipment Enclosures 


Equipment will be installed in indoor and outdoor environments, with 
various levels of sheltering ranging from significant protection to none. 

All outdoor equipment shall be designed for exposure to salt laden marine 
air, fog, rain, hail, and other environmental conditions prevalent in the 
Puget Sound Area. 


(a) 

RFCS equipment shall be able to operate under additional 
environmental requirements presented in the respective subsystem 
technical specifications as applicable. 


(b) 

Enclosures shall include any provisions necessary to maintain the 
internal equipment at an acceptable temperature and humidity. 


(c) 

Enclosures shall be designed to prevent entry of moisture during a 
driving rainstorm and to minimize entry of dust. 


(d) 

Any moisture or dust entering the enclosure shall not cause short 
circuits or equipment failure. 

6.MI-1.7 Environmental Requirements 

1.7.1 

Electromagnetic Compatibility 


The Contractor's approach to electromagnetic compatibility shall ensure 
that the electrical and electronic components and subsystems operate in 
their intended operational environments without being affected by or 
causing harmful interference. Protection shall be provided against radio 
frequency and electromagnetic interference (RFI/EMI) emission sources, 
as well as internal conductive or inductive emissions. 


(a) 

Operation of RFCS equipment shall not be affected by the 
electromagnetic fields generated by utility transmission lines, by 
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an overhead catenary at distances as close as 25 feet, or by local 
power distribution lines at distances as close as 50 feet. 

(b) Operation of RFCS equipment shall not be affected by 
electromagnetic effects present during transit operations such as 
electric trolley buses and light rail vehicles. 

(c) Operation of RFCS equipment shall not affect or be affected by 
equipment in the Bus Tunnel, LRT right-of-way or at WSF 
tenninals. 

(d) Operation of RFCS equipment shall not affect or be affected by 
other on-board equipment including vehicle power supplies, 
radios, automatic vehicle identification systems, and on-board data 
collection and processing equipment. 

(e) Contractor shall describe what provisions shall be included for 
EMI/RFI protection. 

(f) The Contractor shall certify through the Contractor’s expense the 
electromagnetic compatibility of equipment to be furnished. 
(CDRL 32) 

(g) Equipment shall meet applicable codes, standards and specifi¬ 
cations at the time of manufacture. 

(h) On-board equipment and card reading equipment connected to a 
customer service terminal, Sound Transit ticket vending machine 
or other revalue device shall meet the following standards. Subject 
to written approval from the Contract Administrator, the 
Contractor may apply for a waiver of EMC testing under this 
contract for on-board equipment, office-based computer 
equipment, card reading equipment installed at Sound Transit 
ticket vending machines, and other equipment that has received 
EMC certifications and approvals from third parties. All waiver 
requests shall be on a device-by-device basis, and shall include 
backup documentation and certifications in support of the request. 
Any testing waiver issued by the Contract Administrator shall not 
be construed to relieve the Contractor from the requirement that 
the equipment satisfy all applicable codes and standards as 
specified in this Section 6.III-1.7. 


Specification 

Standards 

Electrostatic Discharge 

IEC(EN) 61000-4-2 

Radiated Electric Field 

IEC(EN) 61000-4-3 

Conducted Electric Field 

IEC(EN) 61000-4-6 

Conducted Transient Burst 

IEC(EN) 61000-4-4 
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Conducted Surge 

IEC(EN) 61000-4-5 

Magnetic Fields 

IEC(EN) 61000-4-8 

Emissions 

CISPR22 (EN 5022) 


6.111-1.8 System Documentation 

1.8.1 Documentation Control and Management 

(a) All software and versions used to produce documentation shall be 
provided to and approved by the Contract Administrator. 

(b) All system documentation, including manuals and training 
materials, shall be available for download via a project website. 

(c) Unless otherwise specified at least nine (9) paper and electronic 
copies of documentation shall be provided to the Contract 
Administrator. 

(d) All draft electronic documentation shall be provided in Adobe 
Acrobat PDF format suitable for printing. All final electronic 
documentation shall be provided in both Adobe Acrobat PDF 
format and native file fonnat. 

(e) The Agencies shall have the right to reproduce and reuse all 
documentation, subject to Intellectual Property rights and 
requirements as defined in Division I. In all cases, the Agencies 
shall have the right to reproduce, reuse and distribute all 
documentation within an Agency for the purpose of operating and 
maintaining the RFCS. 

1.8.1.1 Documentation Website 

The Contractor shall establish and manage all system documentation via a 

project website 

(a) All documentation shall be downloadable in a usable fonnat 
through this website. 

(b) Access to the website and access to documents within the website 
shall be user and password controlled and available only to users 
as necessary, as identified by the Contract Administrator. 

(c) The Contractor shall update the website with the latest versions of 
documents throughout the Contract. 

(d) Documentation shall be in the English language. 
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(e) Website structure shall be indexed using system documentation 
type and/or a logical grouping. 

1.8.2 Manuals 

1.8.2.1 General Requirements 

The Contractor shall supply the full complement of manuals and 
documentation required to train Agency personnel to operate and maintain 
all system components installed in or on Agency facilities, or operated by 
the Agencies. Manuals shall be provided according to an agreed upon 
schedule (CDRL 33, Required Manuals Schedule). Manual shall be made 
available in two fonns, on the project website and hard copy final versions 
provided to the Contract Administrator. All manuals shall be: 

(a) In the English language. 

(b) Divided and tabbed into logical and/or functional sections. 

(c) Indexed. 

(d) Cover both the hardware and the software associated with each 
system. 

(e) Updated as required over the life of the Contract to reflect all 
configurations operational in the field. 

(f) Furnished as “Controlled” documents and each manual shall 
contain a unique number. 

i. All revisions shall be issued by manual number. 

ii. Revisions to draft and approved manuals shall be recorded 
on a control list to be maintained in the front of each 
manual. 

iii. The list shall be issued with each revision and shall contain 
the date of the revision and the page references for that 
revision. 

(g) The training documentation shall be separate from the operation 
and maintenance manuals, but may reference those manuals. 
(Training documentation requirements are defined in Section 
6.II-12, “Training Requirements.”) 

1.8.2.2 Paper Format 

(a) Manuals shall be designed to withstand continuous, long-tenn use 
in a commercial environment. 
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(b) Manuals shall lie flat when opened and pennit easy addition and 
replacement of pages. 

(c) Covers for all manuals shall be made from materials that are oil, 
water and wear resistant. 

(d) Pages shall be 8/2 x 11 inch except where otherwise specified and 
double sided. 

(e) Sides of pages intentionally left blank shall be so noted. 

(f) Figures, illustrations, diagrams, and drawings shall be labeled as 
figures. Figures may be a maximum of 11x17 inch, folded to 8 V 2 x 
11 inch with the identification clearly marked. 

1.8.2.3 Computerized Format 

(a) The Contractor shall supply manuals, catalogs, diagrams, views, 
illustrated parts catalog, troubleshooting flow charts, and 
schematic drawings in electronic form on CD ROM in the 
following formats: 

i. Text shall be provided in the latest version (current 
production version at deployment, as agreed to by the 
Contract Administrator) of Adobe Acrobat, and Microsoft 
Word or approved commercially available word processing 
program for native fonnat files. 

ii. Drawings shall be provided in .eps or .dxf file formats. 

iii. Graphics files shall be provided in TIFF, GIF and/or JPEG 
formats. 

(b) The Contractor shall be responsible for updating manuals to reflect 

current RFCS parameters in the event that changes are made to the 

system or operational procedures. Manuals shall be updated and 
maintained by the Contractor throughout the life of the Contract, 
and provided to the Agencies in a timely manner in the formats 
specified above. 

1.8.2.4 System Operations Manual 

Nine (9) copies of the System Operations Manual (CDRL 34) shall be 
provided. The Contractor shall include one (1) copy on an electronic file. 
The document shall include the following: 

(a) Complete diagrams. 

(b) Illustrations. 
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(c) Instructions for operation of the system, including nonnal 
operating and communications procedures. 

(d) Diagnostic procedures. 

(e) Restart/recovery procedures. 

(f) Other necessary procedures for operating the system. 

(g) Complete descriptions of functions necessary for generating 
reports. 

1.8.2.5 System Maintenance Manual 

Nine (9) copies of the System Maintenance Manual (CDRL 35) shall be 
provided. This document shall be comprehensive and shall provide 
complete detailed technical descriptions of maintenance operations, 
including, but not limited to, the following: 

(a) General descriptions. 

(b) Theory of operations. 

(c) Preventive maintenance schedule and activities. 

(d) Troubleshooting techniques. 

(e) Corrective measures, both temporary and permanent. 

(f) Locations and availability of support services for all major 
components. 

(g) Point-to-point component wiring schematics. 

(h) Assembly and disassembly drawings. 

(i) Installation guidelines. 

(]) List of required maintenance tools. Complex tools and test 

equipment each require a separate operators manual (CDRL 36). 

(k) Component parts lists. 

(l) Schematic diagrams. 

1.8.2.6 Software Documentation 

Software Documentation (CDRL 37) shall be provided as described in the 
Contract. 
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1.8.2.7 Current Parts List (CPL) 

The Contractor shall provide a comprehensive and detailed Current Parts 

List (CPL) for each and every component included in the system. Parts 

shall be numerically coded for inventory purposes. 

(a) The CPL (CDRL 38) shall be categorized and related to particular 
system components. 

(b) The CPL shall contain the source vendor’s name, identification 
numbers and codes, or other means to identify the manufacturer of 
each component. 

(c) The CPL shall include prices and quantity discounts offered. 

(d) The CPL shall identify new component and products that will be 
developed for this application, as well as note which products are 
replacing existing equipment. 

6.IIM.9 Audit 

The Contractor shall provide the audit capabilities to track all RFCS transactions 
from conception to settlement. 

(a) The system shall create and maintain an audit trail of accesses to the objects it 
protects. 

(b) The audit mechanism shall permit the specific auditing of the actions of one or 
more users based on the individual’s identity or security/administrative role. 

(c) Audit data shall be protected so that read access to the data is limited to those 
subjects authorized for review of audit data. 
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6.111- 2 Fare Card 

6.MI-2.1 Subsystem Description - Fare Card 

The RFCS fare card will be the regional fare media accepted at all participating 
transit Agencies for fare payment. It is the intent to introduce a contactless-only card 
to support the RFCS project, with the potential to accommodate a dual interface card 
in the future operating in parallel with the contactless-only card. All systems and 
equipment in the RFCS shall support the contactless interface. 

(a) The fare card (DR 101) shall be a memory or microprocessor smart card with 
a contactless interface. The contactless interface shall be used for all 
communications and transaction processing between the fare card and RFCS 
equipment. 

(b) The card shall be technically capable of both reading and updating uniquely 
stored RFCS information through the contactless interface. 

(c) Agency access to any non-RFCS applications that may be resident on the card 
shall be restricted without written authorization from the owner of the non- 
RFCS application. 

(d) The fare card shall be designed to support the addition of a magnetic stripe to 
ABA standards, and be imprinted with custom artwork and photographs on 
the front and back. 

(e) RFCS data shall not be accessible by any non-RFCS application without 
written authorization from the Contract Administrator. 

(f) The fare card shall include an electronic and printed serial number. In the 
event that the electronic serial number differs from the printed serial number: 

i. The Contractor shall provide an electronic file cross referencing 
electronic and printed serial numbers with every card order. 

ii. The RFCS shall provide access to all card information via either 
the electronic or printed serial numbers, and shall maintain a cross- 
reference of the two. 

6.111- 2.2 Functional Requirements - Fare Card 

2.2.1 Card Operating System 

The Contractor shall provide a Card Operating System (COS) that 

conforms to the following requirements (DR 101.01): 

(a) The COS shall support a multi-application structure to allow for 
the creation and addition of new applications without interfering 


Contract 229944 


6.111-22 


April 29, 2003 





Fare Card 


Division III 


with the existing ones. (If multiple applications are used in 
conjunction with an open electronic purse, then any application 
added to the card shall be subject to the approval of the open 
electronic purse association to ensure the integrity of the open 
purse scheme.) 

(b) The COS shall allow the updating and/or the removal of existing 
applications. 

(c) The Contractor shall provide detailed infonnation of how the COS 
will be designed to secure and safeguard the integrity of 
transaction data stored on the card such as the file protection 
function, data encryption algorithms, and/or Message 
Authentication Code (MAC). 

(d) The Contractor shall provide detailed information on how data 
integrity will be maintained and transactions completed for 
contactless operation. 

(e) The transaction speed requirements specified herein shall not be 
impacted by the COS security features design, specifically through 
the card’s contactless interface. The Contractor specifications 
(DR 101.02) in that regard are subject to Program Manager review 
and approval. 

(f) The fare card shall support blocking of Agency issued cards and 
blocking of the RFCS application on a third party issued card. 

i. Requests for card unblocking shall be allowed by an 
authorized customer service representative only. 

ii. The fare card shall support blocking only the RFCS 
application on a non-Agency issued card in a multi¬ 
application environment. 

iii. The blocking and unblocking function shall be controlled 
by the clearinghouse in accordance with the RFCS policy. 

2.2.2 Disposable Card 

The Contractor shall provide disposable contactless-only cards (DR 

101.03) that shall have limited functionality for short term applications in 

targeted markets at a low cost. 

(a) The disposable card shall be configurable in any denomination of 
value or pass validity, or as a visitor, group or special fare 
instrument. 

(b) The Agencies shall be able to order disposable smart cards pre¬ 
valued, or shall be able to value the cards at the time of issuance. 
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2.2.3 Smart Objects (Option) 

The Contractor may provide Smart Objects (e.g. key chains) (DR 101.04) 

that have the contactless hardware embedded into the device. Smart 

Objects may have full RFCS functionality, or limited functionality. 

(a) Smart Objects shall serve specific applications in target markets. 

(b) Smart Objects shall have a unique serial number and may be 
reloadable. 

(c) The use of Smart Objects are subject to successful completion of 
all specified testing requirements. 

2.2.4 RFCA/Facility Access Combination Card 

The Contractor shall provide RFCS/Facility Access Combination Cards 

(Combo Cards) that provide both RFCS and facility access functionality. 

Such cards will be deployed by King County as the KC Employee ORCA 

ID. 

(a) Combo Cards shall meet the requirements of the RFCS Fare Card, 
and shall include functionality as required to communicate with 
facility access control systems that utilize Indala 125kHz, 26 bit 
Weigand proximity technology. 

(b) Facility access functionality shall be for the sole purpose of 
providing employee access to designated facilities. Data or 
information utilized for facility access shall not be used for any 
other purpose without the express written consent of the Contract 
Administrator. 

(c) The Combo Card’s RFCS functionality, including but not limited 
to products, initialization processes, issuance processes, 
transaction processing, and reporting, shall be the same as for the 
RFCS Fare Card. Combo Cards will be considered Institutional 
Program cards. 

(d) Facility access functionality shall be compatible with the 
applicable Indala proximity card reader systems including facility 
codes and Indala card number encoding as provided by King 
County. 

(e) Combo Cards shall be pre-printed with the following information; 
no other information shall be pre-printed without consent of the 
Contract Administrator: 
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a. The face of each Combo Card shall be in a portrait format 
and shall be pre-printed with the Card Serial Number in the 
lower left hand corner and the Card Verification Number in 
the lower right hand corner. The Card Serial Numbers will 
have a first digit that is different from other card types. 

b. The back of each Combo Card shall be in a landscape 
format and shall include only the Indala encoded card serial 
number in the lower right hand comer. 

(f) Combo Cards shall have a glossy finish suitable for secondary 
printing and personalization. King County will be responsible for 
any secondary printing or personalization of cards. 

(g) The Contractor shall be responsible for ordering test Combo Cards 
with Indala encoding as specified by King County unless otherwise 
agreed by the Contract Administrator. King County shall be 
responsible for testing the facility access functionality of the test 
Combo Cards. 

6.111-2.3 Performance Requirements - Fare Card 
2.3.1 Card Reliability 

(a) Card failure is defined as, but not limited to, the inability to 
complete a transaction, the loss of value due to IC chip failure or 
electrical connection, or physical mechanical failure of card 
material, except for physical damage of the card. 

(b) At a minimum, the card shall achieve at least a mean 10,000 
transactions before card failure. 

(c) The Contractor shall provide the Contract Administrator with 
guidelines on verification of a card failure. 

(d) The mean defect rate for cards received in inventory shall be no 
greater than 0.1%. 

(e) The Contractor shall replace all defective cards at no charge 
immediately upon notification. If defective card problems persist, 
the Contractor shall also provide a written report detailing the 
technical explanations behind the causes of the problem, and shall 
correct the problem within 30 days after determination of cause. 

(f) The Contractor shall provide the Agencies with an option to switch 
to a different card supplier for further issuance at no additional 
charge to address reliability issues in a timely manner. 
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2.3.2 Useful Card Life 

For all Agency issued cards, the fare card shall last the earlier of four (4) 
years or 10,000 transactions as stated in 2.3.1 “Card Reliability” when 
used on a daily basis under normal circumstances for fare payment. 

(a) In the event the card graphics are a critical security feature, the 
graphics shall not deteriorate for at least three years when used on 
a daily basis under normal circumstances for fare payment. 

(b) If the RFCS application is loaded on a non-RFCS issued card, then 
the card life may be that of the card as established by the third 
party card issuer. 

(c) The pre-printed design common to all cards shall be sealed under a 
clear plastic laminate to protect the image. 

6.111-2.4 Physical Requirements - Fare Card 

2.4.1 Physical Standards 

All fare cards shall conform with the following: 

(a) Basic physical standards as defined by the International Standards 
Organization (ISO) standards 7810 and 7813. Dimensional 
thickness and physical robustness standards shall not apply to 
disposable cards, provided that height and width dimensions are 
met. 

(b) Specific physical standards for contactless integrated circuit 
proximity remote coupling cards specified in ISO 14443-1 at the 
time of the Final Design Review. In instances where this emerging 
standard (ISO 14443) modifies or constrains other ISO standards 
in order to accommodate the contactless functionality, such 
modifications shall apply to the fare cards. 

2.4.2 Card Memory Storage Capacity 

At a minimum, the memory storage capacity shall be sufficient to support 
all RFCS functions and shall ensure that the card has sufficient memory to 
store at least two other non-transit applications. Additionally the memory 
shall be sufficient to store both the TransAp and OpAp applications 
concurrently. 

(a) The Contractor shall choose and specify the memory capacity of 

the fare card given the requirements specified herein and according 
to the Contractor’s analysis of those data and system requirements 
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including the anticipated addition of RFCS and non-RFCS 
applications to the card. 

(b) The Agencies reserves the right to use the remaining memory on 
Agency issued fare cards for purposes not identified at time of 
Contract award. 

2.4.3 Data on the Regional Fare Card 

The following minimum data segments shall be provided on the “normal 
(non-disposable) fare card (DR 101.05): 

(a) Base Segment 

(b) Agency Data 

(c) RFCS Stored Value Purse 

(d) Pass Products (zero or more) 

(e) Multi-ride Products (zero or more) 

(f) Ride History 

(g) Revalue History 


The way data is stored on a fare card is not specified. 

2.4.3.1 Base Segment (One Per Card) 

The base shall consist of the following minimum data fields: 


Data Field 

Comments 

Card Serial Number 

Regional Fare Card-assigned number 

Card Expiration Date 

Based on life of card 





Passenger Type Indicator 

Adult, RRFP senior, RRFP disabled, youth and other category 

Passenger Vehicle Type Indicator 

Defines the default vehicle type for WSF vehicle ferry travel (up 
to 20 different types; 7 types estimated initially) 

Passenger Type Expiration Date 

Required for temporary disabled 

Cardholder Birth Date 

Optional for RRFP cards or youth 


2.4.3.2 Agency Data (One Segment Per Agency) 


Agency-specific data that needs to be stored on the fare card (not required 
by all agencies). 

(a) This feature shall be transparent to the customer. 
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(b) The Agency Data shall consists of the following minimum data 
fields: 


Data Field 

Comments 














Loyalty meters (as described in the PDR document) will not be 
stored on the fare card. 

Customer Zone or Route Fare Preference 
Preset 

Parameter that indicates the customer’s preference for number 
zones of travel in a multi-zone system (e.g. 1, 2 or 3), or WSF 
route designated by an origin-destination pair. Functionality to be 
included but implemented per Agency policy. 


2.4.3.3 RFCS Stored Value Purse (One Per Card) 

If a card has an RFCS stored value purse, monetary value will be added by 
the add fare process and subtracted through fare calculations. The RFCS 
Stored Value Purse shall consist of the following minimum data field: 


Data Field 

Comments 



Remaining Value on Card 

Current stored value remaining on card. 
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2.4.3.4 Pass Products (For Each Pass Type) 

A card may be loaded with zero or more passes. Only one pass of the same 
type may be currently active for an Agency. The Pass shall consists of the 
following minimum data fields: 


Data Field 

Comments 

Agency 

Agency who issued pass 

Start Date of Pass 

First date for rides 

Expiration Date of Pass 

Last date for rides 

Type of Pass 

e.g. Day Pass, 1 week, 2 week, Monthly, Annual, Employer, 
Campus, Puget Pass 


2.4.3.5 Mulit-Rides 

“10-Day Passes (Trips or Rides)” will be stored as Multi-ride Products, 
rather than 10 individual ride products. This provides additional 
flexibility for the agencies (allowing 20 ride products, for example) as 
well as requiring less storage space on the card. 

A card may be loaded with one or more blocks of stored rides in the form 
of multi-ride products. 

(a) The fare card shall include capacity for at least one multi-ride 
product for each of the participating Agencies. 

(b) Only one multi-ride product of the same type may be currently 
active per Agency. Multi-ride products on the card shall be in 
addition to any active passes for the Agency. 

(c) Multi-ride products may be specified to one Agency, or valid 
across multiple Agencies. 

(d) Each multi-ride product shall include the following minimum data 
fields: 


Data Field 

Comments 

Agency 

Agency who issued stored rides 



Remaining Rides 

Number of rides remaining in the multi-ride product 

Expiration Date 

Latest date, after which the product is no longer valid 
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2.4.3.6 Ride History (Last Ten Rides Per Agency) 

Each time a card is tagged for a new ride, a record is created and the 
oldest record shall be purged. 

(a) The card shall have sufficient capacity to store the last ten (10) 
transactions system wide. 

(b) The Ride History shall consists of the following minimum data 
fields: 


Data Field 

Comments 

Agency Providing Service 

Agency providing ride 

Route/Run/Trip 

Route, run, and trip code as applicable to Agency 

Entry Transaction Location 1 






Ride date 


FTP Number 

FTP ID number 

Time of Transaction 


Amount of Transaction 

Amount decremented from stored value of the card for current ride 
or transfer 

Transaction Code 

Such as: Ride, Reversal, Transfer, Short-payment (fare), Upgrade 
Fare, Exception, including any combination thereof (for example, 
pass transaction with stored value upgrade). 

Terminal Exit Transaction 

(Optional) exit FTP ID number 

Time of Exit 

(Optional) 

Exit Transaction Location 



2.4.3.7 Revalue History (Last Five Value Adds) 


“Revalue History” for all Agencies will be stored in a single, five-record 
revalue log. Same as the ride history, each time a card is revalued with a 
new value or pass, a revalue record is created and the oldest revalue record 
is purged. 

The Revalue History shall consists of the following minimum data fields: 


Data Field 

Comments 

Revalue Type 

Initial value, value add, pass, stored rides, adjustment 



Revaluing Entity 

Agency or Contractor selling value 

Terminal ID of Purchase 


Purchase Date 


Time of Purchase 


Amount of Revalue 
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2.4.4 Graphic Requirements 

All issued fare cards shall conform to a common graphic standard that 
shall be finalized at the final design review. The Contractor shall propose 
a graphics scheme which is consistent with the Agency’s identity 
program. The graphics standard shall be finalized at the final design 
review (DR 101.06). At a minimum, the following elements shall be 
provided on the card: 

(a) The 8-digit portion of the unique Card Serial Number, which is the 
portion used for human interface to the System, will be physically 
printed on the front of the Standard card. This same serial number 
will be printed on the back of the Campus Card. The full 
electronic serial number shall be maintained on the card, per 
applicable ISO standards. 

(b) The serial number placement shall be in conformance with ISO 
7811-3, as constrained by ISO 14443-1 such as the last line from 
top/first line from bottom is unavailable for embossing because of 
the antenna loop in the card. 

(c) Regional Fare Coordination Project logo. 

(d) Local Agency Customer Service Telephone Numbers shall be 
placed on the back of the card along with customer service related 
information. 

(e) Name of the Fare Card Program shall be imprinted on the front of 
the card. 

(f) An area for a cardholder photo shall be available for post 
production print, to use on Employer, Campus and/or RRFP cards. 

(g) An area for a company logo shall be available for post production 
print, for use with Employer and Campus cards. 

(h) Special Graphics shall be provided if the Agencies choose to issue 
“Collector Cards.” 

(i) An area for a magnetic stripe shall be reserved for interfacing with 
automated teller machines (ATM). 

(j) Card Graphics shall use a minimum of four colors. 

(k) Option Signature Panel shall be provided on the back of the card 
to enable Cardholders to identify to whom the card belongs, or to 
differentiate one fare card from another. 
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6.111- 2.5 Testing Requirements and Procedures - Fare Card 

(a) The Contractor shall validate through the FAT tests that RFCS cards meet all 
the Contract requirements for wear, data retention, and interfaces to terminal 
devices. 

(b) The cards used in FAT shall be RFC production cards representative of those 
to be used in the operational RFCS. 

6.MI-2.6 Security Requirements - Fare Card 

2.6.1 Chip Personalization 

The Contractor shall perform chip personalization during the card 
issuance in the presence of a secure access module (SAM) or another 
smart card, which would hold the encryption key(s). 

2.6.2 Privacy 

Each card application shall be protected with a security key that will 
enable only the owner of the application to view the contents of the 
application information stored on the card. Infonnation pertaining to a 
particular application shall not be accessible by the card issuer or the 
owners of any other application residing on the card. 

6.111- 2.7 Agency or Institution Specific Requirements - Fare Card 

2.7.1 Sound Transit 

The RFCS Contractor shall support Sound Transit fare collection 
equipment contractor with integrating the RFCS application on existing 
fare collection equipment. The RFCS contractor shall, under the 
cooperation of Sound Transit, develop the necessary RFCS software that 
will be loaded onto Sound Transit equipment. It is anticipated that 
software will be required for card to reader interface and CDCS to 
clearinghouse. 

2.7.2 Campus Card Model (University of Washington Husky Card) 

The following requirements shall apply to Campus Cards (DR 101.07), 
specifically to the UW Husky Card. These requirements may also apply 
to large institutional organizations. 

2.7.2.1 Card Imprinting Requirements 

The face of each card shall include space for the following university or 
college-specific imprinted information: 

(a) University or college logo 
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(b) 

“Non-Transferable Property of {university or college name}” 

(c) 

Cardholder name 

(d) 

Classification of cardholder such as Staff, Faculty, Student or 
Affiliate 

(e) 

Capability of being imprinted with up to four colors 

(f) 

For student cards only, “Misuse Penalty WAC 478-120 Student 
Conduct Code” 

(g) 

Cardholder photo 

2.7.2.2 Magnetic Stripe Husky Card 

(a) 

Cards will be issued with an ABA standard high coercivity 
magnetic stripe (unencoded at issuance) on the reverse side. 

(b) 

The stripe shall be a maximum .218 in. from top edge of card to tip 
edge of magnetic stripe. Bottom edge of magnetic stripe no less 
than .020 in. from the bottom line of the last track encoded. 

(c) 

The Signal Output level of all stripes must be equivalent to 80%- 
130% of ISO standard output level specified for 2700-4000 

Oersted stripes (as referenced in ISO Specifications 7811-6). 

(d) 

The magnetic stripe shall be capable of passing a test to encode 

UW infonnation and then reading the information in several 
different types of readers on campus. 

(e) 

The magnetic stripe is to be used for campus applications. Use of 
the stripe for other applications or purposes is subject to approval 
by the Contract Administrator and the University of Washington. 

2.7.3 WSF Commercial Account Card 

(a) 

A Commercial ID filed will be added to the Standard Card. 

(b) The Commercial ID will be fixed and not modifiable when the 

Commercial Account Agreement is approved. 

(c) The Commercial ID will be set when the card is issued through a 

Commercial account Card Order and will not be modifiable once set. 

(d) The Commercial Account Name will continue to be displayed as it 

is currently at the websites and CST. 

(e) 

No ERG device will display the Commercial Account ID. 
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(f) The GAK will make the Commercial Account ID available to the 
WSF Electronic Fare System (EFS). 

(g) There will be no Reporting impacts. 


Contract 229944 


6.111-34 


April 29, 2003 





Fare Card 


Division III 





General Requirements Fare Transaction Processor 


Division III 


6.111- 3 General Requirements Fare Transaction Processor (FTP) 

The requirements stated in this Section shall apply to all configurations of fare 
transaction processors supplied under this Contract as described in Section 6.III-4, 

6.111- 8 and 6.III-9; but also, as applicable, to the related modules described in Section 

6.111- 6,6.111-7 and 6.III-10. 

6.111- 3. 1 Subsystem Description - FTP 

The FTP (DR 102) is the region’s fare collection device for the RFCS. The basic 
functionality of all FTPs is essentially the same, only the physical packaging is 
customized for the environment in which it will be used. In addition to collecting 
fares and validating passes, the FTP shall: 

(a) Store transaction history 

(b) Check for blocked cards 

(c) Perform automated revalue 

(d) Dump all transaction data to the Wireless Data On/Off Loading System, if 
directly connected, when a data transfer is initiated. 

3.1.1 FTP Configurations 

The Contractor shall provide the following FTP configurations that will 
read the data on the fare card, process the corresponding transaction, write 
the correct data back to the fare card, and transfer the transaction records 
to the appropriate data acquisition computer (DAC) or directly to the 
clearinghouse system: 

(a) On-Board FTP (OBFTP) - will be used by all Agencies except 
WSF to process fare transactions aboard buses (Section 6.III-4.) 

(b) Portable FTP - are small, hand held devices used in applications 
where the installation of fixed equipment is impractical or 
unnecessary. Examples include vanpool and paratransit 
applications, WSF operations at selected tenninals, and potentially 
on-board commuter and light rail vehicles or at stations. (Section 
6.II-8). 

(c) Stand-Alone FTP - are used primarily in the Sound Transit and 
WSF environments in locations where a fixed, stationary device is 
appropriate. Rail Platfonns and Ferry Docks will have multiple 
stand-alone FTPs which will enable passengers to tag the FTP 
associated with their destination (Section 6.III-9.) 
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3.1.2 FTP Configuration Requirements 

All FTP configurations shall include the following elements that are 
described in the subsequent Subsections: 

(a) Central Processing Unit 

(b) Memory 

(c) Smart Card Interface 

(d) Customer Interface 

(e) Hardware Interface 

6.111-3.2 Functional Requirements - FTP 

The following general FTP functional requirements apply to all configurations of 
FTPs. 

3.2.0 Central Processing Unit 

The FTP central processing unit shall be capable of supporting, at a minimum, the 
following functions: 

(a) Prior to use for fare collection or customer service, the FTP shall initialize 
itself and accept log-on from Agency Personnel. 

(b) The FTP shall provide functionality for the following methods of log-on: 

i. Manual entry/update of log-on infonnation through the DDU 
keypad for On-Board FTPs, keypad entry through Portable FTPs, 
and on-line and laptop connection to Stand Alone FTPs. Manual 
log-on and en-route log-on/updates shall not require the use of a 
smart card. 

ii. For on-board FTPs, transfer of log-on information from a driver ID 
card. For Stand Alone FTPs, log-on information shall be 
transmitted through the communications network. 

(c) Specific data to be entered/uploaded for log-on will vary by agency and will 
be defined at Conceptual Design Review (CDRL 1). As a minimum, FTP log¬ 
on data fields shall include: 

i. Fareset 

ii. Trip Number 

iii. Route Number 

iv. Run Number 

v. Operator ID 
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vi. Capability of accommodating minimum two additional fields (to 
be defined for each Agency as part of CDR) 

(d) The Contractor shall be responsible for developing interfaces in the RFCS 
capable of accepting ASCII files of log-on data from Agency run cutting and 
scheduling systems, tied to Operator ID, for the purpose of upload through the 
RFC system. The Agencies will be responsible for providing the format and 
content of the data and identifying the run cutting and scheduling system to be 
used at Conceptual Design Review (CDRL 1). The Agencies will also be 
responsible for modifications to legacy systems to support data export and 
interface to the RFCS. 

(e) Upon reading a card for fare payment, the FTP shall: 

i. Indicate if the card is valid. A blocked or improper card shall trigger a 
red light on the customer display and an audible warning. 

ii. Display the fare to be deducted and fare basis (e.g. “1 Zone Fare”). 
The fare basis display is required if the Cardholder has a Zone Fare 
Preset established on the card. 

iii. For the Sounder Stand Alone and Portable Fare Transaction 
Processors, also display the Station of Origin, fare paid and change 
the screen that displays “Permit to Travel 2 Zones” to display station 
of origin and fare paid. 

iv. If additional fare is required, display the additional amount. 

v. Make the appropriate deduction, considering any discounts 
applicable, and update any appropriate trip counting data fields. 

vi. Display the remaining value on the card and display an indication of 
special fare or pass type, if used, and any frequency discount which 
has accrued. 

(f) The FTP shall store and process the transaction data for upload to the DAC. 

(g) Using displays, light indicators, and audio tones, the FTP shall provide 
operator and customer feedback for each transaction. 

(h) The FTP shall maintain collected transaction data in the event of a device, 
interface, or power failure. 

(i) The Contractor shall provide a method to ensure the integrity of the data on 
the OBFTP until a successful data exchange with the WDOLS is 
acknowledged. 

(j) The FTP shall store and process a minimum of two (2) fare tables: Current 
and those for the next fare or service change. Fare tables shall contain data for 
a minimum two (2) Agencies, with the active table determined by the transit 
service the coach is operating under. 
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(k) The FTP shall automatically implement fare table transitions for scheduled 
fare changes, holiday fare tables, etc. 

(l) The FTP number, agency owning coach, coach number, and service operated 
under shall be parameters that are retained in the FTP unless modified by the 
system administrator/manager. 

3.2.1 Memory 

3.2.1.1 Capacity 

(a) The FTP shall use solid state memory with sufficient capacity to 
store at a minimum, all data subsequent to the last data upload to 
the DACS including: 

i. Up to 10,000 transaction records. 

ii. 100 log-in / log-off records. 

iii. 100 Event records such as, but not limited to FTP 
malfunctions, failed read attempts, successful and 
unsuccessful data up- and down-loads. 

iv. 6,000 bad card numbers for cards issued to the general 
public. 

v. Card block or status change information for all campus and 
other institutional cards in circulation (capacity is required 
to update the status of all campus cards at an academic 
quarter or semester change, and also to update non-campus 
institutional account cards). 

vi. Secret keys for communication and card access. 

vii. Manager passwords. 

viii. Minimum of two (2) fare tables. 

ix. Automatic card revalue information. 

x. Vehicle identification number or designated location code 
to be programmed at time of installation. 

xi. Additional Agency specific data required for processing 
and reporting local fares and inter-service transfers. 

(b) As transaction volumes increase, FTP memory shall be expandable 
to a capacity of at least five times that for previously listed items i. 
through xi. 

(c) The Contractor shall provide data storage for the OBFTP which 
uses non-volatile memory. 
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3.2.1.2 Captured Ride Data 

Ride data is captured in the FTP when cards are tagged by customers. The 
data is recorded in groups, called intervals. Using the data fields identified 
below and additional fields if necessary, the FTP shall capture and/or 
generate the following data. 

(a) Transaction Header Data (for each recording interval) 

Each interval shares common header data, which applies to each 
transaction in the group. An interval may represent one direction 
of a route (e.g. inbound or outbound or ferry route destination), an 
individual vehicle stop, change in log-on or route/run/trip 
parameters, or it may represent a period of time at a fixed location. 
An example of the possible transaction header data is subsequently 
shown. 


Data Field 

Comments 

Agency Owning Coach 

The agency who owns the coach and FTP. 

Coach Number/Designated 
location code 


FTP Number 


Driver/Seller/Attendant 

Log-on 


Service Operated Under 

Community Transit and King County coaches may be operated as Sound 

Transit contracted service, and/or a private contractor may operate as an 

Agency service. 

Fareset 

The fareset in effect 

Transaction Location 1 

Station 1 or Ferry Terminal 

Transaction Location 2 

Station 2 (if applicable). Route or Vehicle Stop 

Route 

Route number as applicable to each Agency. 

Run 

Run number as applicable to each Agency. 

Trip 

Trip number as applicable to each Agency. 

Service date 


Time of Interval Start 



(b) Transaction Detail (for each captured ride transaction) 

The Transaction Detail shall capture and include the data fields 
listed in Section 2.4.3.1 through 2.4.3.6 (current ride only) in each 
transaction. The Transaction Detail shall also include the following 
additional data fields in each transaction. 


Data Field 

Comments 

Driver/Seller/Attendant 

Log-on 


FTP Number 


Date of Transaction 
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Time of Transaction 


FTP Transaction ID 

Transaction sequence number generated by FTP 


The following set of data fields shall be provided but requires fare policy 
decision for activation. 


Data Field 

Comments 



Terminal Exit Transaction 

Optional by Agency, exit FTP ID 

Time of Exit 

Optional by Agency 

Exit Transaction Location 

Optional by Agency, e.g. GPS or AVL 


3.2.2 Smart Card Interface 

The FTP contactless interface shall meet ISO 14443, parts 2 and 3, and 
shall be in conformance with its most recent release at the time of contract 
execution. Where available from the card manufacturer, the FTP 
contactless interface shall meet ISO 14443 part 4, and shall be in 
confonnance with its most recent release at the time of contract 
execution. 

(a) Power and Signal Interface Standards — The Contractor shall 
confonn to the standards for contactless cards specified in ISO 
14443-2. 

(b) The FTP shall have a communications signal interface that 
conforms with both ISO 14443-2 Type A and ISO 14443-2 Type B 
standards (DR 102.01). 

(c) Initialization and Anti-Collision Protocol 

i. The card and FTP shall accommodate an anti-collision 
protocol preventing erroneous processing when more than 
one card is simultaneously brought within the processing 
range of the FTP. 

ii. The initialization and anti-collision protocols shall conform 
to the specifications of ISO 14443-3. 

iii. In the absence of such a protocol, the Contractor shall 
propose a standard subject to Contract Administrator 
approval. 

iv. Optional: Through operator intervention, such as holding 
down a designated button, an FTP shall be able to process a 
stack of up to five (5) fare cards. This feature is of interest 
to Washington State Ferries to support vehicle-level 
operations where multiple cards may be presented 
simultaneously. This manual override of the anti-collision 
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protocol shall be subject to the review and approval of the 
Contract Administrator. 

(e) The fare card transaction protocol shall conform to the 
specifications of ISO 14443-4, subject to a compliant interface 
being provided by the card manufacturer. 

(f) Operating Range 

i. The card and FTP shall interface within the distances and 
relative orientations defined in ISO 14443. 

ii. RFCS equipment read-write distance shall be adjustable 
from zero to the maximum defined in ISO 14443. 

iii. The distance shall be optimized once the system is in 
operation. 

3.2.3 Customer Interface 

The Contractor shall provide a customer interface and display (DR 

102.02) to provide the customer with transaction status information as 

follows: 

(a) Message indicating the FTP is not operational such as, “OUT OF 
SERVICE”. 

(b) The Contract Administrator will define the message sets and 
formats with the Contractor during the design review process. 

(c) The message sets shall be finalized after the Beta Test program has 
been completed. 

(d) Display messages shall be easily edited on an as needed basis, 
once the system is in operation. 

(e) At a minimum, the following messages shall be provided: 

i. Default or idle message to indicate the system is 
operational such as, “READY.” 

ii. Fare type and amount deducted. 

iii. Remaining value on the card. Activation of this feature for 
Full System Rollout shall be finalized after completion of 
the Beta Test program. 

iv. Indication of an unsuccessful transaction with reason such 
as, “Invalid read/encode - try again,” “Insufficient value,” 
“Invalid card - Call Service Center.” 

v. Indicator that the card has a low remaining value such as 
“low value.” 
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vi. Message sets customized according to inter-Agency 

transfer agreements and fare policy. 


(f) 

The display menu and display messages shall be programmable 
using a developer’s utility, supplied by the Contractor, running on 
a Windows-Intel PC with the capability to upload the modified 
menu or messages to the FTP using a standard PC port. 


(g) 

The messages and displays shall also be modifiable from a central 
location. 

3.2.3.1 

Light Indicator 


(a) 

The FTP shall be equipped with transaction status indicators 
visible to the customer. 


(b) 

These indicators shall consist of a “Green-, Yellow-, and Red- 
Light” to indicate a successful or unsuccessful transaction. 


(c) 

This feature augments the alpha numeric display. Figure III-3.1 
summarizes customer visual indicators. 

3.2.3.2 

Audio Indicator 


(a) 

An audio feedback for indicating the completion of a successful or 
unsuccessful transaction shall be also be provided. 


(b) 

The audio indicators shall be different sounds or different volume 
levels of the same sound. 


(c) 

The FTP sound level shall be controlled with a minimum number 
of keystrokes or adjustments by the operator of the relevant FTP. 


(d) 

The type of audio feedback and the parameters are subject to 
Contract Administrator approval. Figure III-3.1 summarizes 
customer audio indicators. 



Figure 111-3.1 

CUSTOMER INDICATOR MATRIX 


Condition 

Visual Indicator 

Audio Indicator 

Successful Transaction 

Green 

Indicator 1 

Warning - i.e. low card value 

Yellow 

Indicator 2 

Incomplete or failed read 

Yellow Flashing 

Indicator 3 

Unsuccessful Transaction - i.e. 
insufficient value, expired pass, blocked 
card 

Red 

Indicator 4 
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6.MI-3.3 Performance Requirements 

3.3.1 Processing Time 

The processing of a transaction shall be completed within 0.3 seconds 

(300 ms). The following shall be concluded within this time frame: 

(a) Initialization; 

(b) Authentication and other security processes; 

(c) Data Exchange (read and encode); 

(d) Computation of fare, including applicable incentives or discounts; 

(e) Initiate the display of results on the customer (and any other 
applicable) displays. Once initiated, the results shall be displayed 
within an additional 250 ms on the customer (and any other 
applicable) display. 

3.3.2 Accuracy and Reliability 

(a) Accuracy for all types of FTPs is defined as the mean ratio of the 
number of transactions correctly recorded by the FTP, as 
evidenced by the transactional data recorded and stored on the fare 
card, to the number of transactions attempted. 

(b) As part of Factory Acceptance Testing (Section 6.II-11.4.2) and 
Acceptance Testing (Section 6.II-11.4.7), the Contractor shall 
demonstrate a minimum FTP transaction processing accuracy rate 
of 99.99% as identified in Item (a) above. 

(c) The FTP shall have a minimum reliability of 30,000 MOHBF for 
each type of FTP configuration. 

(d) Any single FTP that fails more than two (2) times per month as a 
result of Type II failures as defined in Section 6.II-11.4.8.7.2, 
subsections iii, iv and v, shall be replaced with a new unit. If the 
new unit experiences the same failure rate, the Contractor shall be 
responsible to initiate an investigation to determine why the unit 
fails, and then shall perform repairs, or redesign the unit as 
necessary and replace the existing units with the redesigned units. 
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6.111-3.4 Physical Requirements 

3.4.1 Appearance and Styling 

(a) Each type of FTP shall conform to generally accepted practices in 
appearance and styling, within the limitations of materials used for 
construction, and shall be approved by the Contract Administrator 
at the Preliminary Design Review. (DR 102.03) 

(b) All exterior surfaces shall be clean with all comers rounded. 

(c) There shall be no exposed bolt heads, nuts, sharp edges, or cracks 
on the outside surfaces. 

(d) All displays shall be flush mounted in the enclosures. 

3.4.2 Structural Features 

(a) The finish shall be orbital finished stainless steel, unless specified 
otherwise or approved by the Contract Administrator. The 
following changes have been approved by the Contract 
Administrator: 

1) The DDU and OBFTP will be manufactured from injected 
molded plastics. 

2) The finish of the SAFTP will be non-ferrous bead blasted. 

(b) Provisions shall be incorporated to clear any liquids that may enter 
the device or condensation that may develop. 

3.4.3 Customer Display 

(a) The display shall be water and liquid resistant. 

(b) Any leakage into the unit shall not cause the unit to become non- 

operational. 

(c) The display technology shall be subject to Contract Administrator 
approval and shall meet the following requirements: 

i. Readable under any combination of ambient lighting such 
as direct sunlight and night-time operation; 

ii. At least two lines of alpha-numeric text with a minimum of 
twenty characters readable from 6 feet. 

(d) The display shall resist breakage due to accidental impact from 
hard objects, such as briefcases, during boarding, wheelchair 
handles or other devices used by the disabled community. 
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(e) WSF will require two customer displays at vehicle toll booths. 
Both displays shall show the same messages simultaneously. 

3.4.4 Locks and Security 

(a) Access cover(s) of the FTP housing shall be opened with 
mechanical key(s) for maintenance access to the modules and 
subassemblies. 

(b) The key(s) shall be of a type that is not readily duplicated and 
stamped with the words “NO COPY”. 

(c) Alternative means of securing the internal components shall be 
subject to Contract Administrator approval. 

i. The DDU and OBFTP housings shall be secured to the 
cradle with inaccessible tamperproof screws or similar 
fasteners. Each device shall mechanically lock to its 
cradle. 

ii. The SAFTP will be secured through a mechanical lock on 
the rear access door of the unit. 

iii. The PFTP will not be secured. 

3.4.5 Identification Labels 

(a) A metal identification label inscribed with the FTP serial number 
shall be pennanently attached to the outside of each FTP housing. 

(b) Major subassemblies inside the FTP shall have a permanently 
attached label inscribed with a unique serial number and part 
number prominently located on the subassembly. 

3.4.6 Modularity 

(a) The FTP shall be packaged as a separate unit and not bundled with 
the DDU, WDOLS or Ethernet hub. 

(b) The FTP shall use connectors, approved by the Contract 
Administrator, for all external connections. 

6.111-3.5 Environmental Requirements 

The FTPs and related modules (including the Ethernet hub) shall be designed to 
comply with all applicable FCC regulations concerning conducted and radiated 
emissions of RF energy and shall operate in the environmental conditions provided in 
Figure III-3.2. 
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Figure 111-3.2 

FTP OPERATING ENVIRONMENT 


Parameter 

Minimum Requirement 

Temperature Range: 

+10°F to +110°F operating; -25°F to +150°F storage 

Thermal Shock: 

Per SAE J1455 (Jan 88) Section 4.1.3.2 j 

Thermal Cycle: 

Per SAE J1455 (Jan 88) Section 4.1.3.1 

Humidity: 

20% - 90% relative humidity, non-condensing 

Shock: 

Up to 5g instantaneous and horizontal 

Vibration: 

1.5g (RMS), 5 to 200 Hz 

EMI Susceptibility: 

Example sources: 

Heater and air 
conditioning controls, 
high voltage arcs, 
alternators, radar and 
radio from WSF 
operations, etc. 

Per the requirements of 6.ill-1.7.1(h). 

Other (dust, grit, rain- and 
salt water protection): 

The FTP and associated devices shall have the following 
minimum ratings against the ingress of dust, grit and water: 
Onboard FTP (6.ill-4), Driver Display Unit (6.ill-6), Ethernet 
Hub (6.ill-11) and Radio Control Unit (6.111-6.8.3): IP 44 
Wireless Data On/Off Load System (6.ill-7): IP 42 rating in its 
installed configuration, to be confirmed at Final Design 

Review. 

Stand Alone FTP (6.ill-9): IP 55 

Portable FTP (6.ill-8): IP42 

The Stand Alone FTP shall include additional protection to 
prevent salt water ingress and corrosion when installed in a 
marine environment (e.g. for WSF). This shall include 
protection against direct salt water spray. 


6.MI-3.6 Data Exchange Requirements 

All software and fare table updates shall be uploaded through the RFC system, and 
shall not require manual data upload from a laptop computer, memory card, disk or 
other means. 

The FTP clock shall be synchronized via the DACS clock. Synchronization shall 
occur during data on and offloads. 

3.6.1 Communication Ports 

(a) The FTP shall include as a minimum the following ports: 

i. A high speed serial port to provide the primary data connection to 
the FTP. 

ii. An RS232 port for diagnostics and back-up data transfer. 
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(b) The Contractor shall provide a Communications Interface Specification 
(DR 102.04) for the FTP. This specification shall include a description of 
the data elements and communication protocols for all ports. 

(c) The Communications Interface Specification shall also describe the data 
elements and communications protocols for any additional communication 
ports required by specific FTP configurations per Sections 6.III-4, 6.III-8, 
and 6.III-9. 

3.6.2 FTP Back-Up System 

(a) The Contractor shall provide an alternate means of extracting data 
from the FTP, such as via a laptop computer, subject to Contract 
Administrator review and approval. 

(b) The backup system shall be used primarily to upload captured 
transaction data from the FTP. 

(c) It shall be possible to manually upload/download data files in the 
event of a primary data path failure through an RS232 port. 

(d) In the event of a primary data storage failure or backup battery 
failure, an indication on the display shall alert the operator. 

(e) Correct password entry shall automatically enable the FTP to 
download the transaction data to the back-up device. 

i. Neither the FTP nor the backup device shall retain the 
correct password. 

ii. Unsuccessful attempts to enter the password shall be 
logged at the FTP. 

iii. The log shall contain detailed information including, the 
date, time, location, FTP number, and erroneous password. 

(f) An alternate process for initiating data extraction may be provided 
which shall be subject to Contract Administrator review and 
approval. 

(g) Alternate means of removing data records may be provided. 

i. The Contractor shall provide a detailed description and the 
technical details necessary for Contract Administrator 
evaluation. 

ii. Alternative means of data removal are subject to Contract 
Administrator approval. 


Contract 229944 


6.111-48 


April 29, 2003 





General Requirements Fare Transaction Processor 


Division III 


(h) If the FTP is removed for depot maintenance, the backup method 
shall upload captured transaction data to a depot DAC or to the 
clearinghouse. 

6.MI-3.7 Testing Requirements and Procedures - FTP 

In addition to testing specified in Section 6.II-11.4 “Testing Requirements” the 
following tests shall be perfonned. 

3.7.1 Cycling Test 

Cycling test for each type of FTP shall be perfonned as follows on the 
first unit representative of the production units. 

(a) A minimum of 10,000 transactions, and at least 500 data 
downloads and 200 fare table up-loads shall be conducted. 

(b) Transactions shall be divided evenly among all possible fare 
deduction and Agency transfer transactions of which the device is 
capable. 

(c) The fare amounts shall be representative of those expected to be 
employed in the RFCS. Detailed information regarding the 
transaction types and values to be used in the cycling test shall be 
included in the Detailed Test Procedures and subject to Contract 
Administrator approval. 

3.7.2 Vibration Test 

The Contractor shall ensure that all vehicle fleet vibration conditions 
expected in the area of equipment installation are taken into account to 
ensure that proper isolation/protection is built in to the design of 
equipment that may be used in an on-board environment to accommodate 
the range of frequencies anticipated for the vehicle fleet. The following 
requirements shall be met. 

(a) The FTP components shall be tested per the procedure of MIL- 
STD-810C, Method 514.2, Category f Curve V (1.5g, 5.5 to 200 
Hz) with the following changes: 

- The cycling time shall be two (2) hours on each axis for a 
total of six (6) hours. The equipment shall operate normally 
during and after this acceleration test, and shall not 
experience broken or loosened parts from this vibration. 

- At the conclusion of each axis frequency sweep cycle, the 
equipment shall be subjected to a vibration of three (3) g- 
forces at a frequency sweep between seven (7) and fourteen 
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(14) Hz for a period of one (1) minute and four (4) g-forces 
at a frequency sweep between seventy (70) and one hundred 
and forty (140) Hz for a period of one (1) minute. The 
equipment shall operate normally after these acceleration 
tests and shall not experience broken or loosened parts from 
this vibration. 


3.7.3 Shock Test 

The FTP equipment shall be tested per Procedure I of MIL-STD-810C 

with the following changes: 

(a) The half sine shock pulse shall have a peak value (A) of 5g and a 
duration (D) of 20 milliseconds. 

(b) The on-board equipment shall operate normally after the shock 
tests and shall not have experienced broken or loosened 
components as a consequence of these tests. 

6.111-3.8 Additional Security Requirements - FTP 

The Contractor shall provide a means to prevent unauthorized tampering with a stolen 

or lost FTP and Related Modules. 

(a) The Contractor shall design the FTP to prevent unauthorized recovery of 
electronic value stored in the memory, or “reverse engineering” which would 
compromise the RFC system security. 

(b) Upon loss or disconnection of power, the FTP shall securely power down and 
retain all data. 

(c) Each type of FTP shall be provided with a non-volatile memory for storage of 
the data files for at least 72 hours as described in the System Backup Plan 
(CDRL 5). 
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6.MI-4 On-Board Fare Transaction Processor (OBFTP) 

6.MI-4.1 Subsystem Description - OBFTP 

The Contractor shall provide On-Board Fare Transaction Processors (OBFTP) 
allowing fare cards to be read and encoded through the contactless interface during 
the fare payment process on-board Agency coaches. The OBFTP shall consist of a 
CPU for processing transactions, memory for storing fare tables and transaction 
records, customer display, and card reader (DR 102.05). 

The OBFTP shall be capable of operating, when delivered, in a limited integration 
mode or as a plug-n-play peripheral (full integration mode) on an on-board network 
to be provided by others. Initially, the Agencies expect to operate the OBFTPs with 
a limited degree of integration, and then migrate to a full integration mode when an 
on-board Vehicle Logic Unit (VLU) is developed and installed by others (see Section 
6.III-5). 


A flexible architecture for the OBFTP (DR 102.06) and DDU is required to allow 
each agency to migrate from the limited integration mode to the full integration mode 
at any time in the future, and to accommodate on-board integration requirements and 
architectures that vary by Agency. The OBFTPs, when delivered, shall be capable of 
supporting the following two modes of operation, and shall be designed to allow 
migration from limited to full integration mode without hardware or operating/RFC S 
application software changes, except such hardware and software changes as 
necessary to achieve the objectives of Change Order No. 32. 

The Ethernet switch will be installed as per Section 6.II-11.3 for the purpose of 
providing an environment that allows for developing a modular on board architecture 
as per contract clause 6.III-3.4.6. When installed, the Ethernet switch will function as 
the communications switch for all on-board system traffic for fare collection 
purposes. The Ethernet switch shall provide communications between the OBFTP, 
DDU, and VLU at an Agency’s discretion, shall transfer data to the WDOLs via an 
Ethernet switch/High Speed serial interface when communicating on and off the 
vehicle in FIM. 

4.1.1 Limited Integration Mode (LIM) 

In the Limited Integration Mode, the OBFTP shall store transactions until 
communication with the WDOLS is established and data transfer can be 
completed. The OBFTP shall connect to other on-board devices as 
illustrated in Figures III-4.1 and III-4.2. 
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Figure 111-4.1 (KCM) 

On-Board LIM Architecture for KC Integration 


SWITCH 



Figure III-4.2 identifies the module interfaces that apply to the Limited Integration 
Mode (LIM). 
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Figure 111-4.2 

MODULE INTERFACE SUMMARY - LIM 


Module 

Ethernet 

Switch 

Radio 

Control Unit 

GFI Farebox 
(Option) 

OBFTP 

Ethernet/High 
Speed Serial 

N/A 

N/A 

DDU 

Ethernet/High 
Speed Serial 

J1708 

N/A 

WDOLS 

Ethernet/High 
Speed Serial 

N/A 

N/A 

VLU 

N/A 

N/A 

N/A 


4.1.2 Full Integration Mode (FIM) - King County 

In the Full Integration Mode, the VLU, DDU and the OBFTP shall share the use of the WDOLS 
for coaches owned or operated by King County. When communication is established via the 
WDOLS, then the data transfers for each device will be handled in parallel until all are completed. 
The OBFTP, DDU and WDOLS shall be connected as illustrated in Figures III-4.3 and 111-4.4. 

The Ethernet switch shall act as the interface between the OBFTP, DDU and VLU. The VLU 
shall send data and information as described herein to the DDU. The DDU will share the 
information from the VLU with the (AFC Application) by use of the DDU Common Store. An 
Ethernet/High Speed Serial interface shall be used for on/off-loading data via the WDOLS. Data 
provided by the VLU will include the variables described in Section 6.III-6.8.4, including but not 
limited to: login data (route/run/trip), trip change prompts, fareset changes and, if the ERG option 
exercised, Stop ID data. The AFC Application will update the Common Store variables needed 
by the OBS, including but not limited to: operator login and default trip fareset. 
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Figure III - 4.3 (CT) 

On-Board Architecture for CT Integration 
SWITCH 
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Figure III - 4.3 (PT/ET/KT) 


On-Board Architecture for PT, ET, and KT Integration 


SWITCH 
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Figure III -4.3 (KCM) 


On-Board Architecture (FIM) for KCM Integration 


SWITCH 



Figure III-4.4 identifies the module interfaces that apply to the Full Integration Mode 
(FIM). The Contractor may suggest alternative on-board configurations in addition to 
the configuration provided, subject to the review and approval of the Contract 
Administrator. 
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Figure 111-4.4 

MODULE INTERFACE SUMMARY - FIM 


Module 

Ethernet 

Switch 

Radio 

Control Unit 

GFI Farebox 
(Option) 

OBFTP 

Ethernet/High 
Speed Serial 

N/A 

N/A 

DDU 

Ethernet/High 
Speed Serial 

N/A 

N/A 

WDOLS 

Ethernet/High 
Speed Serial 

N/A 

N/A 

VLU 

Ethernet/High 
Speed Serial 

N/A 

N/A 


6.111- 4.2 Functional Requirements - OBFTP 

The following functional requirements supplement those stated in Section 6.III-3.2. 

(a) The OBFTP shall accept driver input through the Driver Display Unit (DDU) 
for security, data collection, and operational purposes. 

(b) The OBFTP shall transfer data to and from the DAC via a wireless off/on 
loading system, Section 6.III-7. 

(c) The OBFTP shall include capabilities to accept and transfer to the DDU log¬ 
on data (driver ID, and initial route, run, block, trip, starting fareset and other 
log-on data) from a driver smart card. 

6.111- 4.3 Performance Requirements - OBFTP 

The following performance requirements supplement those stated in Section 6.III-3.3. 

(a) The placement of the OBFTP shall promote an accelerated throughput of 
passengers. 

(b) The minimum throughput rate for OBFTP shall be 30 passengers per minute. 

(c) The throughput rates assume passengers familiar with system operation with a 
valid fare card, no mis-reads or cards with insufficient value, and no 
automatic revalue. 

(d) The Contractor shall conduct a human factors analysis with regard to the 
placement of the OBFTP and confirm the results of the analysis through the 
human factors test in accordance with Section 6.II-11.4.1. 
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6.111- 4.4 Physical Requirements - OBFTP 

The following physical requirements supplement those stated in Section 6.III-3.4. 

4.4.1 Dimensions and Layout 

A prototype of each OBFTP configuration and its mounting (DR 102.07) 
shall be demonstrated at time of PDR on each Agency bus type mounting 
location. Access to the vehicles will be coordinated through the Contract 
Administrator. 

4.4.2 Structural Features 

(a) All on-board equipment provided under this contract shall resist 
shocks equal to 5.0g without pennanent defonnation or failure of 
mounts or diminution of operational characteristics of any 
subsystems. 

(b) The OBFTP enclosure shall be stainless steel or approved 
alternative subject to the approval of the Contract Administrator. 

6.111- 4.5 Electrical Requirements - OBFTP 

Equipment installed on-board transit vehicles shall meet the following power supply 
requirements: 

(a) Nominal voltage: 12 to 24 volts DC nominal (car or bus battery) 

(b) Operating range: 9 to 39 volts DC 

(c) Equipment shall be able to withstand sustained voltage levels of up to 
48 VDC for up to ten (10) minutes. 

(d) Equipment shall not suffer damage or lose data in memory when the supply is 
increased to 48 VDC. 

(e) Equipment shall not suffer corruption of data when the power dips below 
9 VDC. 

(f) Equipment shall not be damaged by very high (twenty [20] times nominal 
voltage) short duration (up to ten [10] milliseconds) peak voltage. 

(g) Contractor shall indicate full operational and quiescent power drain for each 
on-board module proposed. 

6.111- 4.6 Data Exchange Requirements - OBFTP 

The following data exchange requirements supplement those stated in Section 6.III- 
3.6. 
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(a) To the extent possible, data communications between the OBFTP and other 
on-board devices shall comply with the applicable Transit Communications 
Interface Profiles (TCIP) standards that are in effect at the time of Notice to 
Proceed. 

(b) Communications between on-board devices shall be as described in Section 
6.III-4.1. 

(c) The Contractor shall provide the drivers and the interface software for the 
OBFTP, and shall provide an interface specification for future connection to a 
VLU. 

(d) The OBFTP shall include a diagnostic port and have the capabilities to allow 
configuration changes and system maintenance activities to occur through the 
use of a laptop computer. Any configuration changes and/or system 
maintenance activities conducted shall be accounted for in the FTP memory 
and a record shall be transferred to the clearinghouse during the next fare card 
transaction data transfer. 

(e) The OBFTP shall include the ability to interface with a commercially 
available Global Positioning System (GPS) through an available port, and tag 
transactions with location infonnation. 

6.111-4.7 Installation Requirements - OBFTP 

The Contractor shall work with designated staff from each Agency to determine on¬ 
board equipment location and installation restrictions, requirements and 
configurations. The joint consultation will include a prototype installation on each 
vehicle type in each Agency’s fleet as described below. Any RFCS equipment 
mounted in a vehicle is subject to review and approval of the relevant Agency. Any 
modifications to existing stanchions or equipment (e.g. fareboxes) must be approved 
by the affected Agency. 

(a) All mounting hardware associated with the OBFTPs shall be provided by the 
Contractor. 

(b) Available mounting options shall include as a minimum: mounting on vertical 
stanchions, mounting above, in front of, or below horizontal stanchions, and 
mounting on horizontal or vertical dash or other flat surfaces. 

(c) The mounting hardware and the OBFTP shall be positioned such that it 
minimizes encroachment on the passenger and the driver, and does not 
obstruct the driver’s right mirror field of vision and view to the right front of 
the bus including the view of the front door. 

(d) The OBFTP mounting location shall allow ease of driver entry and exit from 
the driver’s compartment with no risk of injury such as knees. 
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(e) The Contractor shall provide a flexible mounting system that allows the 
mounting location to be optimized, maximizing passenger throughput and 
driver operability and comfort. 

(f) The Contractor shall provide measurements and schematic drawings of any 
required stanchion modifications for each vehicle type and stanchion 
configuration. 

(g) Equipment installation shall be prototyped for each coach type at each 
Agency. The Contractor is advised that although similar coach types are in 
use at different Agencies, the interior configuration may be different. At a 
minimum, the prototyping process shall be as follows: 

i. At Conceptual Design Review, the Contractor shall supply each 
Agency with a set of typical brackets, mounting hardware, and 
wiring such that Agency staff can test alternative equipment 
configurations. 

ii. At Preliminary Design Review, the Contractor shall conduct a site 
survey of all coach types at each Agency, and working with 
Agency staff identify preferred installation, mounting and wiring 
of onboard equipment for each coach type. 

iii. At Final Design Review, the Contractor shall finalize all mounting 
hardware, subject to approval by the Agency impacted. At the 
discretion of each Agency, final design shall be based on a) an 
Agency provided prototype or mock-up of the hardware, b) the 
Agency providing design details or drawings describing preferred 
installation, or c) the Contractor generating design details and 
recommendations. In any event, the Contractor shall be 
responsible for the preparation of all final design and fabrication 
documentation, molds, prototypes, and other materials required for 
equipment installation. 

iv. Upon fabrication of the first article of installation hardware, the 
Contractor shall conduct a site survey of all coach types at each 
Agency to verify the correct design and fabrication of the 
hardware, and confirm suitability. 

(h) The Contractor shall provide fixed mounting hardware. The Contractor shall 
provide adjustable hardware as a Contract Option to be negotiated and 
exercised at the discretion of an Agency. 

(i) Stanchion modifications will be the responsibility of each Agency. 

6.111-4.8 Rear Door FTP Units (Option) 

The Contractor shall propose an option for the provision of rear-door fare transaction 
processors for Agencies who are considering all-door loading. Rear door FTP units 
shall meet the following additional requirements: 
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(a) Rear door FTPs shall meet the installation requirements described in Section 
6.III-4.7. 

(b) Rear door FTPs shall be slaved to the DDU or master FTP at the front door. 

(c) The operator shall not be required to enter additional log-on, parameter 
change or other data to initialize rear door readers or change status. 

(d) The operator shall have the capability of de-activating (turning off) the rear 
door readers from the DDU, independent of the front door reader. 

(e) A consolidated fare transaction data set for all readers on the vehicle shall be 
provided that includes the device ID of each reader. 
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6.MI-5 Vehicle Logic Unit (VLU) - [Provided by others] 

The information about the VLU in this Section is provided for information purposes 
only. 

6.111-5.1 Subsystem Description - VLU 

The VLU will be installed by others for the purpose of evolving to a fully integrated 
on-board system. This is referred to as the Full Integration Mode (FIM). When 
installed, the VLU will function as the on-board server or central processor. The 
VLU act as the communications interface between the OBFTP and WDOLS, 
tunneling data between the two devices. The VLU will also support multiple, 
concurrent applications such as vehicle location, passenger counting, vehicle 
operating data, stop annunciation and other functions, and will store and buffer data 
from these systems for off-load by the WDOLS. 

As part of the transition from Limited Integration Mode (LIM) to FIM, 

• the WDOLS connection will be moved from the OBFTP to the VLU, and data 
exchange with the data acquisition computer (DAC) will occur through the 
VLU; and 

• the connection to the DDU will be moved to the VLU, and the operator 
interface with the OBFTP will occur through the VLU. 

It is envisioned that the VLU and OBFTP will maintain exactly the same fare 
transaction data file, which will be verified upon data exchange, until cleared with 
instructions from the DAC. The DAC will segregate the data and forward all Smart 
Card transaction data to the clearinghouse. 
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6.111- 6 Driver Display Unit (DDU) 

6.111- 6.1 Subsystem Description - DDU 

The Driver Display Unit (DDU) shall display OBFTP information and provide the human 
interface for interacting with on-board systems. The DDU (DR 103) shall consist of a 
software programmable display with programmable soft keys on the perimeter. 

The DDU shall be designed to provide real-time operation and control of a minimum of six (6) 
additional on-board systems or applications. Provided as information in Appendix F is an 
example “Conceptual King County Driver Display Unit Operating Concept”. This document 
provides a conceptual example for King County of how the DDU might operate in a multi¬ 
application on-board environment. 

In keeping with an open, modular system architecture, the Contractor shall provide a DDU that 
is packaged separately and not bundled with the FTP or WDOLS. 

6.MI-6.2 Functional Requirements - DDU 
6.2.1 Keyboard 

The keyboard (DR 103.01) shall provide the human interface with the OBFTP and 

other onboard subsystems. 

(a) The DDU keypad shall provide manual log-on (sign on) and log-off 
capabilities per the requirements of Section 6.III-3.2.0, and shall include 
functionality as required to support transfer of log-on information via the 
WDOLS. 

(b) The DDU shall transfer log-on data/changes to all connected devices 
through a single keypad entry or data transfer from a driver smart card. The 
DDU shall not require multiple re-entry of log-on data/changes to initialize 
multiple on-board devices. 

(c) The DDU shall be provided with a minimum of sixteen (16) programmable 
soft keys around the perimeter of the display (display keypad). The 
Contractor may propose a reduced key keypad provided that all 
functionality can be met, subject to approval by the Contract Administrator 
at Final Design Review. 

(d) The driver shall be able to enter fare set/category, fall-back voice radio 
channel, operator identification, run, route or time segmentation data and 
any other agency specific data on the driver keypad, either as a primary data 
entry or as a backup to any vehicle location system which may be installed 
to support this function. 
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(e) The display keypad shall be capable of assigning keys such that multiple 
onboard functions can be controlled on each display “page”. E.g. some 
keys on a display page may be assigned to RFCS, while others may be 
assigned to the radio, PA, or other onboard functions. 

(f) The display keypad shall allow a return to the main screen or menu from 
any sub-level screen or menu with one key press. 

(g) The system shall be able to collect transaction data in the event incorrect 
log-on data is entered by the driver, or when no log-on is entered at all, the 
driver shall be alerted through an audible alarm, and a flashing message on 
the driver display. 

(h) The display keypad shall be software programmable, and shall allow a 
driver to conduct, as a minimum, the following smart card-related 
functions: 

i. Override default fare payment parameters upon notification by the 
customer (e.g. override default settings to pay multiple fares from 
one card, pay for a “day pass”, pay for a special or promotional fare, 
pay for a passenger of with a different fare basis, pay for a customer 
traveling a greater number of zones than their Zone Fare Preference 
Preset, etc.) 

ii. Conduct a fare transaction reversal (enabled only subject to Agency 
policy). 

iii. Charge an upgrade fare for a customer traveling a greater number of 
zones than their Zone Fare Preference Preset after the initial 
transaction has occurred. 

iv. Operate the farebox and other on-board systems in the FIM and FIM 
modes. 

(i) The display keypad shall be software configurable to /replace manual 
counters used with non-registering fare boxes, providing the ability to 
record non-smart card boardings through keypad data entry. 

(k) The display keypad and control logic shall be designed to minimize 

operator keystrokes. High priority functions (as defined by the Agencies 
during Conceptual Design Review) shall be located at the top level (first 
page) of the display. Medium and low priority/use functions shall be 
accessible within 2 additional keystrokes. 


Contract 229944 


6.111-64 


April 29, 2003 





Driver Display Unit 


Division III 


6.2.2 Display 

The display (DR 103.02) shall allow monitoring of the OBFTP and any connected 

subsystems. 

(a) The message display area of the LCD shall allow monitoring of the OBFTP 
status and mirror the customer display during each transaction. 

(b) The message display area of the LCD shall not be overwritten with softkey 
labels except insofar as approved during Conceptual Design Review 
(CDRL 1). 

(c) The display shall serve as the monitor for interfacing with the FTP and any 
other connected subsystems for system maintenance and configuration 
changes. 

(d) The display shall be capable of displaying status information for multiple 
onboard functions simultaneously. E.g. the display may simultaneously 
display fareset, radio information, route-run information, etc. 

(e) The display shall display current time in hh:mm:ss format in characters 
sufficiently large to be read by the driver when seated. 

(f) The Agencies will define the message sets and formats with the Contractor 
during the design review process (DR 103.03). 

6.111-6.3 Performance Requirements - DDU 

The DDU technology shall be subject to Contract Administrator approval and shall meet the 

following requirements: 

(a) Readable in all lighting conditions encountered on a bus during day and night, such as 
direct sunlight or driving in rural areas with limited outdoor lighting. 

(b) The DDU shall have a minimum reliability of 30,000 MOHBF. 

(c) All keys or buttons shall have a minimum 10 year service life in normal operation, 
regardless of number of actuations. In the event that a key or button fails before the 10 
year service life, it shall be replace at no cost to the Agencies per Section 4.1 of Exhibit 
14 of the Contract provided such failure does not constitute an Agency responsibility 
as defined in Section 4.2 of Exhibit 14. 

(d) The DDU shall continue to function and operate other onboard devices in the event of 
OBFTP failure. 

(e) The DDU shall be self-restarting, and shall not become unresponsive or require manual 
reboots or restarts to continue operation. 
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(f) Upon removal of power from the ignition sense input of the device, the FTP and DDU 
shall execute automatic logoff and automatic power down functions with timeouts 
determined through configuration data. 

(g) The DDU shall include an automatic timed logoff function, initiated by removal of 
vehicle power at the ignition sense input of the DDU. In the event the operator does 
not logoff, removal of power from the ignition sense will automatically initiate the 
DDU logoff process after an Agency-configurable time period has expired. Such 
periods shall be configurable on an Agency by Agency basis. 

(h) The automatic logoff function shall be cancelled and reset if the power to the ignition 
sense is restored prior to expiration of the automatic logoff timer. 

(i) The automatic logoff function shall be cancelled and reset if the vehicle master switch 
is turned to any “run” position prior to expiration of the automatic logoff timer. 

6.111- 6.4 Physical Requirements - DDU 

The DDU shall meet the physical requirements in Section 6.III-4.4 and the following: 

(a) The DDU shall be designed to be water and liquid resistant, and the enclosure shall be 
water and liquid tight. 

(b) Any leakage into the unit shall not cause the unit to become non-operational. 

(c) The DDU shall resist breakage due to accidental impacts from hard objects, such as 
briefcases during boarding, or wheelchair handles or other devices used by the disabled 
community. 

(d) DDU shall incorporate a back-lighted LCD graphics display with controls to turn the 
backlighting off and on, and vary the intensity of the display. 

(e) The message display area of the LCD graphics display shall be a minimum of 240x128 
pixels (landscape format). 

(f) All softkey assignments shall be displayed outside of the message display area of the 
LCD display. 

(g) The Agencies require the overall size of the DDU to be the minimum feasible within 
these specifications and human factors requirements, as space within the driver 
compartment of the vehicles is very limited. The Contractor shall include scale 
drawings and mock-ups of the proposed DDU showing all dimensions. 

6.111- 6.5 Electrical Requirements - DDU 

The electrical requirements specified in Section 6.III-4.5 shall apply to the DDU. 
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6.111- 6.6 Data Exchange Requirements - DDU 

(a) The DDU shall contain at a minimum the following interfaces (DR 25) as illustrated in the 
Figures contained in Section 6.III-4.1.1 and 4.1.2: 

i. One (1) J1708 communications interface. 

ii. One (1) RS232 communications interfaces for Agency use for controlling 
other devices. 

iii. One (1) RS232 communications interface for diagnostic purposes. 

iv. One (1) Ethernet/high speed serial communications interface. 

v. One (1) RS485 Communication interface for Agency use for controlling the 
other devices. 

6.111- 6.7 Installation Requirements - DDU 

The DDU shall be installed in accordance with the requirements specified in Section 6.III-4.7 

as they apply to a DDU. 

6.MI-6.8 Integration Requirements - DDU 

6.8.1 General Integration Requirements 

(a) The DDU shall be fully integrated with other RFCS subsystems. 

(b) The Contractor shall cooperate and coordinate with Agency staff and other vendors to 
install and integrate additional applications on the DDU, and provide integration as 
described herein. 

(c) The DDU shall be designed to migrate from LIM to FIM integration without hardware 
changes or software upgrade. 

(d) The driver display unit shall have the capabilities to replace the existing King County 
Mobile Data Tenninal (MDT) as the universal display/keypad device, and shall be 
adaptable by any agency to accommodate integration with their future on-board 
systems. 

(e) The Contractor shall develop the necessary software to support the on-board operations 
of the RFCS. The Contractor’s software shall be integrated with software developed 
by others that supports existing systems. 

(f) The DDU shall be supplied with all required software tools, documentation, simulation 
and test routines, and other information as required to allow modification or the 
creation/installation of new applications by the Agencies. 

(g) As part of Design Documentation, the Contractor shall provide a fully detailed 
interface control document for all interfaces to third party devices (DR 103.04). 
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(h) The return state of each on-board system (default state or last active state) shall be 
defined by the Agencies. 

(i) The priority of on-board systems and functions ( assignments and messages on the 
primary and other screens) shall be subject to Agency review and approval during 
Conceptual, Preliminary and Final design. These priorities must be modifiable by the 
Agencies as required. 

(j) The DDU shall be capable of operating multiple on-board systems concurrently. These 
systems must be able to operate in an integrated manner (e.g. operate other on-board 
devices and display their status without interrupting fare collection processing and 
display). 

(k) The DDU shall not require interconnection with the FTP or other onboard devices to 
function. 

(l) Each Agency shall be able to configure key assignments, screen assignments, and 
menu structures independent of that of other Agencies. 

6.8.2 Electronic Registering Farebox integration (Option) 

(a) The Contractor shall develop an interface from the DDU to GFI registering 
fareboxes via the MIU. The interface between the DDU and the MIU shall 
be as agreed between the contractor and McCain Traffic Supply. The 
interface shall be documented (McCain Interface Specification) by McCain 
Traffic Supply and supplied to the Contractor. 

(b) The contractor shall develop the hardware, software, and firmware required 
to provide log-on, log-off, en-route trip change and other messages from the 
DDU through a RS485 port interface to the MIU. 

(c) Messages shall be sent between the DDU and MIU as detailed within the 
McCain Interface Specification in order to support the functionality 
described within the subsequent sections of 6.8.2 and 6.8.4. 

(d) The DDU shall include the capability of providing multiple 
transmissions/re-tries of a log-on/log-off/trip change message without 
acknowledgment. The number of retries shall be a user configurable 
parameter 

(e) The DDU shall include the capability of registering an acknowledgment of 
a message received from the MIU. 
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6.8.3 King County Radio Control Unit (RCU) Development and Integration 
(Option) 

6.8.3.1 RCU Conceptual Design 

(a) The following tasks shall be completed by the Contractor as part of the RCU Conceptual Design: 

Task 1 Review existing RCU prototype documentation. 

Task 2 Conduct interviews and/or discussion groups with King County Staff. 

Task 3 Conduct interviews with the person who developed the original RCU prototype. 

Task 4 Develop and submit a Conceptual Design for the RCU, including the deliverables 

provided in (c) below, to be reviewed in accordance with Section 3.1-27.5 of the 
Contract. 

(b) The objective of the RCU Conceptual Design Review (“CDR”) is to familiarize 
King County with the Contractor’s intended design activities, resolve external interfaces, 
and provide the basis for proceeding to Preliminary Design. Additionally, it will provide 
a foundation for the Parties to commence negotiations regarding a future change order 
for full design and production of the RCU. The CDR shall be performed in accordance 
with the provisions of the Contract. 


(c) The Contractor shall submit the following deliverables as part of the Conceptual 
Design Review: 


Schedule Review 
Functional Block Diagram 
Data Model 

Design Review Item 

Narrative 

Interfaces 

King County Environment 

Physical Dimensions 
Power Requirements 
Decisions 
Problems 

Proposed Price 


Schedule compliance review and discussion of variances or delays. 

Provide a functional block diagram of the system and equipment. 

Provide a top-level data model illustrating the major functional entities 
and relationships 

Provide an outline of Design Review (DR) item 103.6 from Figure II- 
11.3 in the Contract. 

Provide a narrative description of the RCU as proposed by ERG, 
including components supplies by subcontractors. 

Identify all interfaces between the RCU and other on-board devices, 
provide a schedule, and identify responsibilities for completion of 
detailed definition of the interfaces. 

Confirm that ERG is familiar with the operations and maintenance 
environment for the RCU. 

Provide physical dimensions of the proposed RCU. 

Identify power and facility requirements for the RCU. 

Identify information needs and decisions required from King County. 

Provide description of problem tracking, resolution and reporting 
process. 

Provide a proposed unit price for the RCU. 
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6.8.3.2 

(a) 


(b) 


(c) 


(d) 

(e) 

(f) 

(g) 


Design Completion and Development of RCU (if authorized by subsequent 
Change Order) 

The Contractor shall develop a Radio Control Unit for King County (DR 
103.06) to interface with on-board devices as illustrated in Section 6.III- 
4.1. The primary purpose of this device is to operate King County’s legacy 
radio/AVL system. Additional infonnation is contained in Appendix E, and 
prototype documentation (from a previous project) will be made available 
from King County at or prior to Conceptual Design. 

The RCU shall enable existing King County Mobile Data Units (MDU) to 
interface to the legacy 450 MHz GE Delta-S radio and current model 
Motorola or Ericsson 450 MHz radios. 

The Contractor shall develop a production version of the RCU based on a 
current King County prototype. Work activities shall include: 

i. DDU-RCU design and software interfaces. 

ii. Obtain test bench equipment (to be provided by KCM): 

• GE Delta-S radio 

• MDU (Mobile Data Unit) 

• Radio handset 

• PA microphone 

• Emergency alarm switch 

• Inside and outside public address speakers 

iii. Confirm whether to use J1708 or other protocol for 
communications. 

iv. Complete programming and software development to support 
required RCU functionality. 

v. Test prototype on a bench 

vi. Field test prototype. Test procedures shall be approved by the 
Contract Administrator. 

vii. Manufacture production units. 

viii. Conduct functional, performance, EMI, RFI and environmental 
testing. 

The Contractor shall integrate the RCU with the DDU. 

The DDU shall be designed to migrate from LIM to FIM integration 
without hardware changes or software upgrade. 

Implementation shall be per the requirements of Section 6.II-11.1.2.3. 

When the ARI/MDU is in Init Mode, the driver must log-on to the radio 
system through the DDU in order to receive or originate calls. Whenever 
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the ARI/MDU is in Init Mode, the DDU shall immediately display the 
following message on the screen, and shall sound an audible warning. The 
message shall consist of the following: 

RADIO LOGGED OFF 

PRESS OK TO CONTINUE 

OK 

When the driver presses the “OK” key, the DDU will proceed to the logoff 
sequence. The “Radio Logged Off’ message shall be displayed until the 
“OK” key is pressed, or until the DDU executes an automatic logoff. 
Triggering of an automatic DDU logoff shall not be affected by ARI/MDU 
status. 

6.8.4 Community Transit Integration 

(a) The DDU shall include application softwar to communicate with the 
McCain Traffic Supply interface board (MIU). The MIU will control the 
following devices on Community Transit vehicles (DR 103.07): 

i. Transit signal priority (TSP). 

ii. Destination sign. 

iii. GFI Farebox (per section 6.8.2). 

(b) Log-on data shall be transmitted to the MIU. 

(c) Starting trip information shall be validated in the DDU and transmitted to 
the MIU. 

(d) Run list shall be compiled and displayed on the DDU. 

(e) The driver shall be able to select the next trip number, and the DDU shall 
transfer updated trip data to the MIU. 

(f) Community Transit requires that the following data be stored, on-board in 
the RFC System: 

(i) Current (Prior to the transmission to the destination sign, at which 
time it should be deleted) and pending destination sign configuration 
files (for the future transmission to the destination sign, at which 
time it should be deleted); 

(ii) Current and pending trip information; 

(iii) Run list. 
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(g) The Agencies shall provide two (2) MIUs and the software interface 
specifications to the Contractor at its office in Seattle, Washington in 
sufficient time to permit the Contractor to accomplish the work in 
accordance with the Baseline Project Schedule (CDRL 42). The MIUs so 
provided shall be 80% to 90% fully developed, capable of controlling the 
GFI farebox, the TSP and the destination sign and capable integrating with 
the DDU. The MIU shall further contain a test mode capable of returning 
appropriate infonnation to the DDU on receipt of messages from the DDU. 

EXHIBIT 6.111-6.1 

PRELIMINARY CT TRIP DATA FILE FORMAT 


Field Number 

Field Length 

Abbrev. 

Length 

Contents 

1 

2 

1 

Owner / Operator 

2 

10 

6 

Effective date 

3 

1 

1 

Days of operation 

4 

8 

1 

Schedule (Weekday, Saturday, 
Sunday) 

5 

3 

3 

Route 

6 

4 

4 

Run 

7 

5 

5 

Trip 

8 

5 

4 

Start of trip (hh:mm) 

9 

5 

1 

Direction of travel 

10 

1 

1 

Fareset 

11 

20 

20 

Unused (to include TSP or 
other data as needed) 


64 47 


Contract 229944 


6.111-72 


April 29, 2003 









Driver Display Unit 


Division ill 


6.8.5 King County Full Integration Mode (FIM) 

6.8.5.1 General 

The Contractor shall provide applications, software, test elements, and testing for the 
integration of the Driver Display Unit (DDU) with the On-Board Systems (OBS) being 
developed by another vendor (OBS/CCS vendor). Such integration shall be implemented on 
King County coaches and Sound Transit coaches operated by King County (hereinafter 
collectively referred to as KCM coaches). 

The DDU shall be modified to provide for two modes of operation: 

1. Limited Integration Mode (LIM) representing the current (pre-OBS) condition and 
operations, as well as the current condition and operations of all other Agencies. 

2. Full Integration Mode (FIM) representing King County on-board system operation 
when the OBS equipment is installed and operational. 

Modifications to the DDU shall not adversely affect operation on the device on other (non- 
King County or Sound Transit coaches operated by others) coaches or services, or introduce 
additional steps or workload for the operators of those services. 

As required in Section 6.III-6.8.1 and 6.8.3, the DDU will be integrated with the RCU and 
King County’s existing on-board systems in limited integration mode (LIM) until all KCM 
coaches have new OBS and Transit Radio Systems installed. For FIM, the Contractor shall 
provide design, development and testing documentation, software tools and test apparatus, as 
agreed upon by the Parties, for the OBC/CCS vendor to develop a new on-board non-RFCS 
application (“OBS Application”) that will reside on the KCM DDU platform and integrate 
with the VLU (Vehicle Logic Unit) being supplied by the OBS/CCS vendor. 

The Contractor shall be responsible for development, modification, integration and testing of 
all RFCS software on the DDU, RCU and On-Board Fare Transaction Processor (OBFTP) as 
required to provide the functionality described herein, and maintain RFCS fare collection 
functionality and operations. All applicable devices in the KCM coaches shall be updated 
with new software containing the OBS Application and updated AFC and RCU applications as 
required to support both LIM and FIM functionality prior to the first phase of installation of 
OBS equipment. 

For purposes of this Section, the following tenns shall have the following meanings: 

a. Automatic Fare Collection (AFC) Application: Contractor-developed RFCS software that 
is necessary to meet the requirements of this Section, including on-board software related 
to the DDU and OBFTP, as well as any test and back office software that is created or 
revised to meet the requirements of this Section. 

b. DDU Monitor Application: Contractor-developed application to be provided to the 
OBS/CCS vendor for display of additional DDU Common Store variables and variable sets 
via diagnostic interface. 
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c. OBS Application: the non-RFCS application to be developed by the OBS/CCS vendor and 
loaded onto the DDU, which will integrate with the Vehicle Logic Unit (VLU). The VLU, 
in turn, manages the OBS devices and interfaces, such as the new 700 MHz radio system. 

d. OBS Stub Application: Contractor-developed application to be deployed to all RFCS 
coaches to communicate configuration status to the AFC application. LIM mode will be 
the default configuration until the OBS Application detects the presence of OBS 
equipment. 

e. RCU Application: Contractor-developed software required to operate the King County 
Radio Control Unit (RCU) and provide functionality described in 6.8.5.4 of this Change 
Order. 

6.8.5.2 DDU Monitor Application 

The Contractor shall provide a DDU Monitor Application, which will be a development tool 

for displaying additional DDU Common Store variables and variable sets via a diagnostic 

interface. 

6.8.5.3 OBS Stub Application/Test Harness 

a. The Contractor shall develop an OBS Stub Application, the role of which is to 
communicate to the AFC Application, via the FIMConfig mechanism, described below, 
that LIM mode is enabled in the absence of OBS equipment. The Stub Application will be 
deployed to all RFCS Agency coaches as part of the revisions to the AFC Application 
prior to implementation of the OBS Application in order to confirm that changes to the 
AFC Application have not affected RFCS functionality. On coaches operated by King 
County, the OBS Stub Application will be replaced by the OBS Application once it is 
available and has been certified by the Contractor per the provision of Section 4.0 of this 
Change Order. 

b. The Contractor shall provide a testing capability for OBS operations that affect the DDU. 
A set of test commands will be created via the DDU Monitor Application. These test 
commands will be limited to providing a mechanism to manually modify and validate the 
contents of the new variable sets added to the DDU Common Store in order to implement 
this Change Order. 

c. The OBS Stub Application may also be used as a development tool to provide simulation 
of various on-board operations to aid in the development of software for AFC Application 
integration. 

6.8.5.4 RCU Application 

a. Rather than duplicate a large number of existing DDU template resources, the OBS 
Application and RCU Application will share the appropriate existing template resources. 
The decision on which of these applications accesses the shared template resources is to be 
made by the OBS Application based on whether or not FIM mode is enabled. 
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b. The Contractor shall modify the RCU Application to only access the existing template 
resource once LIM mode had been detected. In the case of FIM mode being detected, the 
RCU Application shall be modified to behave in a passive manner to allow the OBS 
Application to gain access to the existing template resources and perform the desired FIM 
mode operations. 

c. The operation of the existing RCU Application shall be maintained for LIM until every 
KCM coach has been equipped for FIM. 

6.8.5.5 OBS Application and AFC Application Changes for FIM Configuration 

a. The OBS Application shall be separate and distinct form the existing RCU Application 
that interfaces with the legacy KCM radio system. The operation of the existing RCU 
Application shall be maintained for LIM until every KCM vehicle has been equipped for 
FIM. 

b. The OBS Application shall be downloaded by the Contractor to the DDU prior to 
installation of OBS hardware per an agreed upon schedule. The OBS Application will 
detect the presence (FIM mode) or absence (LIM mode) of OBS hardware. The OBS 
Application will provide integration status to the DDU and AFC applications which shall 
self-configure accordingly without the need for driver input or action. 

c. The OBS Application will notify the AFC Applications of the integration state (either LIM 
or FIM) so that operations with legacy radio equipment via the RCU Application can be 
maintained until the deployment of OBS hardware on each vehicle. The Contractor shall 
provide a mechanism via the DDU Common Store that allows the OBS Application to 
communicate this infonnation to the AFC application. This mechanism shall be referred to 
as FIMConfig. 

Login Process 

d. From the user viewpoint the login screens and process will appear the same in LIM and 
FIM. For FIM, the login process will be shared between the AFC and OBS Applications. 
The AFC Application will continue to manage Operator login and validation. The AFC 
Application will provide the Operator login data and status to the OBS via the DDU 
Common Store. 

e. The OBS Application shall take over the responsibility of managing rout/run entry and trip 
selection and will also be responsible for the communication of the resulting trip login 
information to the AFC Application. To support this recruitment, the Contractor shall 
provide a mechanism via the AFC Application, using the DDU Commons Store that allows 
the OBS Application to communicate login information to the AFC application is required. 
This mechanism will be referred to as FIMTripInfo. 

f. An agency-defined, unique Trip ID will be provided by KCM to the OBS and RFCS 
devices. Across a year’s three major service changes and the bi-weekly Configuration 
Data (CD) distributions, these Trip IDs will not be re-used. Also, for the life of major 
service change, a Trip ID will always refer to the same trip. These two conditions are 
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required to avoid undetected mismatches in datasets between the two systems. The 
Contractor shall modify CD fonnats to allow such agency Trip ID to be delivered to the 
DDU/OBFTP. 

Automatic Next Trip Selection 

g. To support the OBS-Initiated route/run/trip selection requirement, the Contractor shall 
provide functionality to enable the implementation of the following sequence of events 
while in FIM mode: 

1. At a point in time just prior to reaching the end of trip location, the OBS 
Application shall direct the DDU to display a message in its VLS window 
asking the driver to confirm the change to the next trip, and also display the 
“Start Next Trip” icon for the driver to press the associated key to trigger this 
confirmation. 

2. After the Operator presses the “Next Trip” button, the OBS Application shall 
notify the AFC Application of the change to the next trip via the FIMTripInfo 
mechanism. 

3. The AFC Application shall validate the trip information provided by the OBS 
Application. If an error occurs, an error message shall be returned to the OBS 
Application via the FIMResult mechanism. If successful, the AFC Application 
shall complete the change to the next trip, communicate the appropriate 
information as positive feedback to the OBS application and set the AFC device 
mode to “On-Trip.” 

4. New trip and fare information shall be displayed on the DDU. 

Automatic Fare Change at Zone Boundaries 

h. To support the OBS-initiated fare change requirement, the Contractor shall provide 
functionality to enable the implementation of the following sequence of events while in 
FIM mode: 

1. The AFC CD will set the default fare table and initial Distance Code at the start 
of each trip. The fare table defines the range of fare alternatives that are 
possible for the selected trip. 

2. The Contractor shall provide functionality for the OBS Application to 
communicate a desired fare change to the OBFTP based on the vehicle’s 
location. This mechanism will be referred to as FIMFareset. 

3. The Contractor shall provide functionality for the AFC Application to 
communicate to the OBS Application whether or not the driver has manually 
changed the current default fare since the start of the current trip. This 
mechanism will be referred to as FIMStatus. 


Contract 229944 


6.111-76 


April 29, 2003 





Driver Display Unit 


Division III 


4. The Contractor shall provide for the AFC Application to communicate to the 
OBS Application whether any OBS-communicated fare set change was 
successful or unsuccessful and return the result as FIMResult. 

5. If the AFC Application is on-trip and it receives a request by the OBS 
Application to change the current default Distance Code via the FIMFareset 
mechanism, and the driver has NOT manually changed the current distance 
code since the start of the current trip, then the AFC Application shall: 

o Automatically change the current default fare in use by the AFC 
Application, and 

o Notify the OBS Application that the request was successful via the 
FIMResult mechanism. 

6. If the AFC Application is on-trip and it receives a request by the OBS 
Application to change the current default fare via the FIMFareset mechanism, 
and the driver has manually changed the current fare since the start of the 
current trip, then the AFC Application shall: 

o Notify the OBS Application that the request was unsuccessful via the 
FIMResult mechanism. 

7. When the driver manually changes the default fare on the AFC Application via 
the Change Fare function, the AFC Application shall notify the OBS 
Application of this via the FIMStatus mechanism. 

8. The initial Trip Distance Code, fare table(s) and peak/off peak designator, will 
come from RFCS CD as exported by KCM. The default fare can be overridden 
by the driver and the driver will retain the ability to manually select from the 
available fare tables for the trip. 

9. OBS initiated fareset changes will be limited to the valid distance codes in the 
AFC designated default fare table. 

10. The OBS Application shall not include functionality to automatically set or 
change the fare table as part of the fareset change. 

11. When the Operator begins a new trip the AFC Application will reset the default 
fare table and Distance code for that trip. 

6.8.5.6 CCS Initiated Changes 

a. While operator login/logoff will still generally be perfonned by the existing DDU 
applications, the OBS Application also will be able to automatically initiate an operator 
login/logoff or update certain login-related parameters such as route/run/trip selection. 
Such commands will be issued by the OBS based on instructions sent from the 
Communications Center System (CCS) by a Communications Coordinator (dispatcher). 
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Such operation shall be referred to as a “CCS-Initiated” login/logoff or login parameter 
change (route/run/trip). To support this requirement, the Contractor shall provide 
functionality in the AFC Application (using the DDU Common Store) to allow the OBS 
Application to communicate operator login, operator logoff to the AFC Applications via 
the FIMLogon mechanism, and/or route/run/trip selection to the AFC Applications via the 
FIMTripInfo mechanism. When a Coordinator using the Communications Center System 
(CCS) provides the OBS Application with an operator ID to log in, a password is not 
required. 

b. The Contractor shall provide functionality in the AFC Application (using the DDU 
Common Store) to communicate the result of CCS-Initiated Operator login/logoff and/or 
route/run/trip selection back to the OBS Application via the FIMResult mechanism. 

c. To support the CCS-Initiated operator login requirement, the Contractor shall provide 
functionality to enable the implementation of the following sequence of events while in 
FIM mode: 

1. The OBS Application shall communicate the required information via the 
FIMLogon mechanism as specified above. 

2. The AFC Application shall validate the information provided by the OBS 
Application as required for fare collection operation. 

3. If a validation error occurs, an error message shall be returned to the OBS 
Application via the FIMResult mechanism. If successful, the AFC application 
shall complete the login process, communicate the appropriate information as 
positive feedback to the OBS Application and set the DDU/OBFTP device 
Mode to “Off-Trip.” 

4. The OBS Application shall determine whether or not to display Route/Run 
Entry and Trip Selection screens before triggering a route/run/trip change. 

d. To support the CCS-Initiated operated logoff requirement, the Contractor shall provide 
functionality to enable the implementation of the following sequence of events while in 
FIM mode: 

1. The OBS Application shall communicate the required information via the 
FIMLogon mechanism. 

2. If an error occurs with logoff, an error message shall be returned to the OBS 
Application via the FIMResult mechanism. If successful, the AFC Application 
shall complete the logoff, communicate the appropriate information as positive 
feedback to the OBS Application, and set the DDU/OBFTP device mode to 
“Login.” 

3. The AFC Application shall display the nonnal login screen sequence. 

6.8.5.7 Display of Debugging/Maintenance Variables 
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The Contractor shall provide a mechanism via the DDU Common Store for the OBS 
Application to display a set of 10 variables for debugging/maintenance purposes. The values 
of these variables shall be provided via the DDU’s diagnostic port. The OBS/CCS vendor will 
be responsible for providing a list of such variables and their descriptions. 


6.8.6 Discussion with King County and its OBS Contractor 

a. The Contractor shall participate in pre-design discussion with representative of the 
County and the OBS/CCS contractor regarding the following: 

1. Possible alternative approaches integrating the DDU with 
OBS/CCS and TRS; 

2. Any modifications to, and applications on, the DDU that 
may be required to implement the integration approach(s); 

3. The information sharing and coordination activities that may 
be required between the Contractor and the OBS/CCS 
contractor in order to perform necessary design, 
development and testing; 

4. The technical issues that will need to be resolved as the 
design process proceeds, and the mechanism for resolution; 
and 

5. The process that Contract uses to certify any new 
applications developed. 

In addition to such pre-design discussions, the Contractor staff shall promptly 
undertake such research, drafting and other work as necessary to support these pre¬ 
design discussions, subject to the limits provided below in Section 2.0. The 
Contractor, the County and the OBS/CCS contractor shall attempt to develop by June 
30, 2007, an agreed approach to the integration and a schedule of tasks required to 
complete the design efforts during the OBS/CCS contractor’s design phase. 

b. The Contractor agrees to make the necessary technical staff available for said 
discussions, including at a minimum the Contractor 


1. Configuration Data (CD) as it relates to the import, management and 
formatting of KCM-generated block, route, trip and other operational data, 
handling of CD as the various tiers of the RFC system and management of 
CD consistent sets. 
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2. Transmission to, and management of, configuration data on the Driver 
Display Unit (DDU), including knowledge of file fonnats, compression 
algorithms, security provisions, etc. as they apply to CD payloads 
transmitted from the Data Acquisition Computer (DAC) to the 
DDU/OBFTP. 

3. Low-level DDU software and software driver functionality, including 
particular drivers and interfaces to third party applications and external 
devices as contemplated in Full Integration Mode (FIM). 

4. DDU screen, key and template configuration and management. 

5. Application management on the DDU. 

6. Read/write access to shared memory areas of the DDU, and procedures for 
accessing shared data. 

7. Third party application testing and certification processes as they apply to 
the DDU. 

c. The Parties anticipate such discussion shall occur between April 1 and June 30, 
2007. The County shall work with the Contractor to schedule the relevant 
Contractor staff for telephone or in-person meetings at County request. The 
Contractor will exercise its best efforts to make the relevant staff available when 
requested by the County, provided the Contractor is given at least two weeks of 
advance notice for any in-person meetings. 

d. The results of the pre-design discussions will be recorded in a tabular from by 
County representatives and provided to the Contractor, with such record 
representing the understanding of the Parties with respect to the issues identified in 
1.1. Within fourteen (14) calendar days of receipt of this record, the Contractor 
shall either confirm or modify the record to reflect Contractors understanding. 

e. The meeting and infonnation sharing described above are contingent upon the 
county’s contractor(s) entering into a Non-Disclosure Agreement with ERG. 


6.8.6 Discussion with King County and its OBS Contractor 

a. The Contractor shall participate in pre-design discussion with representatives of the 
County and the OBS/CCS contractor regarding the following: 

i. Possible alternative approaches integrating the DDU with OBS/CCS and 
TRS; 

2 Any modifications to, and applications on, the DDU that may be required to 
implement the integration approach(s); 
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3 The information sharing and coordination activities that may be required 
between the Contractor and the OBS/CCS contractor in order to perform 
necessary design, development and testing; 

4 The technical issues that will need to be resolved as the design process 
proceeds, and the mechanism for resolution, and 

5 The process that Contractor uses to certify any new applications developed. 

In addition to such pre-design discussions, the Contractor staff shall promptly undertake 
such research, drafting and other work as necessary to support these pre-design 
discussions, subject to the limits provided below in Section 2.0. The Contractor, the 
County and the OBS/CCS contractor shall attempt to develop by June 30, 2007, an agreed 
approach to the integration and a schedule of tasks required to complete the design efforts 
during the OBS/CCS contractor’s design phase. 

b. The Contractor agrees to make the necessary technical staff available for said 
discussion, including at a minimum the Contractor staff that are qualified in the 
following areas of the RFCS project: 

1. Configuration Data (CD) as it related to the import, management and fonnatting of KCM- 
generated block, route, trip and other operational data, handling of CD at 
the various tiers of the RFC system, and management of CD consistent 
sets. 2. Transmission to, and management of, 

configuration data on the Driver Display Unit (DDU), including 
knowledge of file formats, compression algorithms, security provisions, 
etc. as they apply to CD payloads transmitted from the Data Acquisition 
Computer (DAC) to the DDU/OBFTP. 

3. Low-level DDU software and software driver functionality, including in 
particular drivers and interfaces to third party applications and external 
devices as contemplated in Full Integration Mode (FIM). 

4. DDU screen, key and template configuration and management. 

5. Application management on the DDU. 

6. Read/write access to shared memory areas of the DDU, and procedures for 
accessing shared data. 

7. Third party application testing and certification processes as they apply to 
the DDU. 

c. The parties anticipate such discussion shall occur between April 1 and June 30, 2007. 
The County shall work with the Contractor to schedule the relevant Contractor staff for 
telephone or in-person meetings at County request. The Contractor will exercise its 
best efforts to make the relevant staff available when requested by the County, 
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provided the Contractor is given at least two weeks of advance notice for any in-person 
meetings. 

d. The results of the pre-design discussions will be recorded in a tabular from by County 
representatives and provided to the Contractor, with such record representing the 
understanding of the Parties with respect to the issues identified in 1.1. Within 
fourteen (14) calendar days of receipt of this record, the Contractor shall either confirm 
or modify the record to reflect Contractor’s understanding. 

e. The meeting and infonnation sharing described above are contingent upon the county’s 
contractor(s) entering into a Non-Disclosure Agreement with ERG. 


6.8.7 Application Certification 

(a) The Contractor shall provide a process and facilities for certifying new applications 
created on the DDU (DR 103.08) including: 

i. Contractor Developed DDU applications. 

ii. Agency Developed DDU applications. 

(b) Contractor Developed Applications: 

i. The Contractor shall provide processes and facilities for the Contractor to 
certify that any new application does not impact other DDU applications or 
functionality. 

ii. The Contractor shall certify that any new application does not impact other 
DDU applications or functionality. 

(c) Agency Developed Applications: 

i. The Contractor shall provide processes and facilities to certify that a new 
application developed by or on the behalf of the Agencies, does not impact 
RFCS functionality. 

ii. The Contractor shall provide processes and facilities to certify that a new 
application developed by or on behalf of the Agencies, does not impact 
other (non-RFCS) DDU functionality. 

iii. The Contractor shall provide processes and tools for an Agency to test and 
certify that a new application does not impact other (non-RFCS) DDU 
applications. 
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(d) Any additional applications shall be certified prior to release in the RFCS. 
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6.111- 7 Wireless Data On/Off Loading System (WDOLS) 

6.111- 7.1 Subsystem Description 

The Contractor shall provide a Wireless Data On/Off Loading System (WDOLS) (DR 
104) as the primary method for permitting connectivity from any Ethernet-enabled 
on-bus device to DACS or other fixed-location equipment. Also, the WDOLS may 
be used to transfer data from FTPs in remote locations where installing a hard wire 
communications link is the less cost effective solution, e.g. stand-alone FTPs located 
on docks in the WSF environment or platfonns in the Sound Transit environment, or 
portable FTPs equipped with a wireless client adapter. The proposed technology shall 
be subject to the review and approval of the Contract Administrator. 

In order to support on-board integration in the bus environment, the WDOFS shall be 
a stand-alone unit connected initially to the Ethernet Switch, and reconfigurable such 
that it can be connected in the future to a VFU. High speed (> 1 Mbps) data 
throughput is required in order to support future data on/off load requirements that 
will extend beyond the RFCS data. 

6.111- 7.2 Functional Requirements 

(a) The WDOFS shall automatically provide wireless connectivity, subject to 
appropriate network access, when a bus or other FTP equipped with WDOFS 
communications capabilities (DR 104.01) enters the range of operation 

(b) WDOFS equipment at transit bases or other fixed locations (DR 104.02) shall 
be able to communicate with all WDOFS equipped buses, regardless of 
agency. 

(c) Vehicles shall not be required to stop during the data exchange. 

i. The Contractor shall indicate the maximum vehicle speed to permit 
successful data exchange. 

ii. The vehicle speed limit shall be subject to Contract Administrator 
approval prior to implementation. 

(d) At a minimum, the WDOFS shall be used for the following: 

i. Uploading of transaction data captured at the FTP 

ii. Downloading of files such as: 

- Software configuration files 

- FTP initialization 

- Fare tables 

- Blocked card list 

- Automatic revalue list, if used 
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- Other operational parameter tables 

6.111- 7.3 Performance Requirements - WDOLS 

The data transmission speed shall be sufficient to on- and off-load on-board 

transaction data from the entire fleet or designated remotely located FTPs, at a 

minimum on a daily basis. 

(a) The WDOLS data transfer process shall be transparent to current operations 
and shall not require operational modifications. 

(b) The WDOLS shall have a minimum reliability of 30,000 MOHBF. 

(c) The WDOLS Access Point(s) shall provide coverage for a range of at least 
1000 feet between the vehicles and external antenna units. 

(d) The data exchange rate shall be a minimum of 1 megabit per second either for 
a single channel device, or an aggregate of 1 megabit per second for a multi¬ 
channel, simultaneous communications device. 

(e) The data exchange shall not be affected by other Radio Frequency (RF) 
sources or transmissions. 

(f) The WDOLS shall confonn to the IEEE 802.lib communications standard or 
Contract Administrator approved equivalent. 

(g) The WDOLS shall include features to support future upgrade to emerging 
IEEE 802. IX standards. 

(h) The on-board WDOLS shall be compatible with existing Cisco Aironet 350 
equipment, and shall not interfere with other 802.lib data transfer systems. 

6.111- 7.4 Physical Requirements - WDOLS 

(a) In keeping with a modular, open architecture, the WDOLS shall be packaged 
separately, and not bundled with the FTP or DDU. 

(b) The enclosure materials shall be high strength polycarbonate, cast aluminum, 
stainless steel or equivalent subject to the review and approval of the Contract 
Administrator. 

(c) Enclosure shall be vandal resistant, flame retardant and resistant to common 
solvents and cleaning materials. 

(d) The WDOLS shall be sealed to prevent any degradation in operation due to 
the accumulation of dust, salt, mud, detergents, solvents, or moisture. 

(e) Any outdoor mounted equipment shall be rated for operation in an exposed 
environment. 
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6.111- 7.5 Electrical Requirements - WDOLS 

7.5.1 Vehicle Mounted Equipment 

The electrical requirements specified in Section 6.III-4.5 shall apply to all 
vehicle mounted WDOLS equipment. 

7.5.2 Base or Terminal Mounted Equipment 

The electrical requirements specified in Section 6.Ill-1.6 shall apply to all 
base or terminal mounted WDOLS equipment. 

6.111- 7.6 Data Exchange Requirements - WDOLS 

(a) The Contractor shall provide a high-speed serial communications device that 
meets the performance requirements in 6.III-7.3. In the initial, limited 
integration mode (LIM), the WDOLS shall be connected directly to the 
Ethernet Switch. In the future, full integration mode (FIM), the WDOLS 
shall be disconnected from the Ethernet Switch and connected to the VLU. 

(b) Communications between the WDOLS and Ethernet Switch/VLU shall be by 
high speed (1Mbps or greater) serial communications. 

(c) The WDOLS shall include data integrity features such as, but not limited to, a 
check to ensure that the data to be downloaded has been captured by the FTP 
and a check to ensure that no duplicate downloads or uploads of data occur. 

(d) In the event of a failed data exchange attempt, the system shall sound an alarm 
at the DDU and the DAC, and log the event in the FTP and the DAC. 

(e) Immediately following the failed data exchange event, the DAC shall notify 
the clearinghouse of the event. 

(f) The WDOLS shall also provide anti-collision such that multiple vehicles can 
be parked in the same area without loss or corruption of data. 

(g) The WDOLS shall be capable of handling data from multiple on-board 
sources, such as the APC system, AVL system, electronic farebox, and 
various engine/vehicle monitoring systems. 

(h) The Base WDOLS shall be capable of sorting multiple data types into 
appropriately labeled files that can be managed with standard data 
management software. 

(i) The contractor shall propose troubleshooting tools that allow agency staff to 
identify and fix data exchange problems occurring in the WDOLS. 
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(]) The Contractor shall provide a method, subject to Contract Administrator 

approval, of managing the data exchange to ensure that the appropriate data is 
exchanged at the appropriate location and time (DR 104.03). 

(k) The WDOLS shall include security protections (DR 104.04) over and above 
Wired Equivalency Protections to guard against: 

i. Unauthorized access to RFCS data transferred via the WDOLS. 

ii. Unauthorized access to Agency networks through the wireless 
system. 

(l) The WDOLS communications approach and security provisions (DR 104.04) 
shall be subject to approval by each Agency’s designated network security 
group or manager. 

(m) The WDOLS security provisions shall conform to Agency policies or 
specifications for IEEE 802.11 based wireless technology. Policies and/or 
specifications shall be provided to the Contractor at Conceptual Design 
Review. 

(n) The WDOLS shall be designed to migrate from LIM to FIM, where the VLU 
or other means will be provided for management of data transferred to or from 
the vehicle. 

6.MI-7.7 Installation Requirements - WDOLS 

7.7.1 Vehicle Mounted Equipment 

(a) Any WDOLS related equipment on-board any vehicle shall meet 
the requirements in Section 6.III-4.7. 

(b) The antenna location(s) for each agency shall be subject to 
approval by the respective agencies. 

(c) Any exterior mounted equipment shall be sealed to prevent leakage 
of rain or bus washer fluids through the life of the installation. 

7.7.2 Operating Base Mounted Equipment 

(a) The antenna shall be mounted in or near a location approved by the 
Contract Administrator. 

(b) The Contractor shall finalize the locations of any externally 
mounted antennas with the Contract Administrator during the 
design review process (DR 42). 

(c) The Contractor shall mount all WDOLS related equipment and 
shall make all power and communications connections. 
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6.111- 8 Portable Fare Transaction Processor (PFTP) 

6.111- 8. 1 Subsystem Description - Portable FTP 

The Contractor shall provide portable FTPs for Agencies that have a need for a 
portable card reading and transaction processing device. 

The Portable FTP (DR 105) shall be a handheld, ruggedized unit operated by Agency 
personnel to process RFCS transactions in a mobile or portable environment. The 
PFTP will be powered by a rechargeable battery that can be recharged by placing the 
unit in a 1 lOVAC-powered cradle or in a 12VDC powered cradle or mount for in- 
vehicle use. 

The PFTP shall be supplied in two configurations: 

As a limited function, verifier only PFTP (DR 105.01) for Sound Transit proof of 
payment fare inspection. The unit shall be light, have low power consumption, 
and be able to conduct fare verification with minimal operation by the fare 
inspector. 

A full-function PFTP (DR 105.02) for agencies such as WSF and Kitsap Transit, 
and potentially for paratransit and vanpool applications. 

The Portable FTP (PFTP) shall, at a minimum, consist of the modules listed in 
Figure III-8. 1 . 


Figure 111-8.1 

PFTP CONFIGURATION SUMMARY 


Modules 

Portable 

FTP 

Central Processing Unit 

X 

Contactless Card Interface 

X 

Customer Display/Indicator 

X 

Standard Battery 

X 

Belt Carry Case 

O 

Shoulder Carry Case 

O 

110 VAC Charger/Cradle -1 Unit 

O 

USB to Ethernet Cable for 1 Unit Charger/Cradle 

O 

110 VAC Charger/Cradle - 4 Units w/ Ethernet 

O 

12 VDC Charger/Cradle 

O 

Wireless Radio (RA2041) 

O* 

Dial-Up Modem & Cable (may be external) 

O* 

High Capacity Battery 

O 

Bar Code Scanner 

O 

Pistol Grip 

O 

RAM B101 Vehicle Mount for PFTP 

O 


“X” denotes module required by Contract and included in the Contract price 

schedule. 
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“O” denotes optional module that shall be available as a priced option, also 
included in Contract price schedule. 

* Certain Agencies require that the PFTP be equipped with a wireless radio 
(Psion RA0241) based on 802.11 technology, or with an external modem, 
depending on the requirements of each Agency. Quantities and configurations to 
be finalized at the time of order. 


6.111-8.2 Functional Requirements - Portable FTP 

The following functional requirements supplement those stated in Section 6.III-3.2. 

(a) Log-on from Agency personnel shall occur via a log-on smart card or through 
a built-in PFTP keypad. 

(b) For ferry applications (Washington State Ferries, Kitsap Transit, and potential 
future ferry services), the operator shall be able to select a destination and 
associated fare basis through the portable FTP keypad. 

(c) Except as noted in (e), the PFTP shall require no interaction other than the tag 
of a card within an Agency-configurable timeout period to perform card 
inspections. The timeout period shall automatically reset in the event of any 
of the following: 

i. The card inspection mode of the PFTP has been selected. 

ii. Inspection mode is re-activated by the inspector after a timeout. 

iii. A previous inspection has been completed. 

(d) The verifier-only PFTP shall record inspection counts by fare category, fare 
type, operator ID, and time segment. 

(e) The verifier-only PFTP shall include functionality to inspect a card status 
including “tagged-in” or “tagged-out” status, and time of last transaction. 

(f) The verifier-only PFTP shall allow and Agency to detennine whether or not 
an operator is required to enter/select route and run depending on what service 
the verifier is sued on or assigned to. 

(g) For Sound Transit, route and run selection will be required for SOUNDER 
commuter rail services, gut not for LINK light rail services. An additional 
Agency sub-type classification shall be added to the Sound Transit 
configuration of the verifier-only PFTP to allow switching the PFTP between 
“SOUNDER” and “LINK LRT” using the device maintenance screen. 
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(h) The PFTP shall allow the operator to override a default fare transaction (e.g. 
to pay for multiple fares from a single card, or to pay a fare other than the 
default). 

(i) The full function PFTP shall perform all functions of the verifier, plus, 

Agency personnel shall be able to: 

i. Determine card balance, number of stored rides on the card, or the 
existence of a pass. 

ii. Provide historical infonnation to the Cardholder by scrolling 
through the transaction history of the last ten transactions stored on 
the card. 

(j) The PFTP application for WSF shall be designed to accept and process both 
RFCS smart cards and Washington State Ferries Electronic Fare System 
media. 

(k) PFTPs for KT applications shall include the following functionality: 

i. An aggregate count of all (farecard and non-farecard combined) fare 
transactions that occur in a trip shall be recorded and displayed on the 
PFTP screen. Passenger counters shall reset with each new trip start. 

ii. Buttons and/or touchscreen icons shall be identified for the purpose of 
recording non-farecard ridership counts. Buttons/touchscreen icons shall 
be allocated for KT fare categories, and ridership counts shall be 
generated/updated on pressing of the ridership button/icon. 

iii. A next trip button shall be included for quick commencement of the next 
trip in the run schedule. 

iv. Activation of data transmission to the DACS shall be periodically initiated 
by the operator at such time as the operator is near a WDOLS location. In 
the event that an operator is unable to initiate data transmission at the end 
of a shift, the PFTP shall remain fully functional and all data shall be 
transferred the next time a data transmission is initiated. 

v. The Operator Role shall include sufficient permission to initiate a data 
transfer. 
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6.MI-8.3 Physical Requirements - Portable FTP 

8.3.1 Dimensions and Layout 

A sample mockup of each PFTP configuration and its display message 

sets shall be demonstrated at time of PDR. (DR 105.01 and 105.02) 

8.3.2 Structural Features 

(a) The PFTP shall be to be light weight and constructed of materials 
suitable for transit and ferry operations. 

(b) The PFTP shall have a simple built-in keypad to allow operation of 
the device. 

(c) The enclosure shall be corrosion resistant and finished to resist 
abrasion and scratching. 

(d) The unit must be sealed and ruggedized to operate in an outdoor 
marine environment. 

(e) Color and type of finish shall be such that it minimizes reflections, 
cracking and peeling and shall be approved by the Contract 
Administrator during the preliminary design review. 

(f) The PFTP shall be configured such that the smart card reader is 
installed in the end furthest from the operator to support “arms 
length” card reading. 

8.3.3 Carry Case 

(a) The Contractor shall supply a carry case with the PFTP. 

(b) The carry case shall be of durable construction and materials. 

(c) The carry case shall be designed to be carried on a belt. 

6.111-8.4 Electrical Requirements - Portable FTP 

8.4.1 Rechargeable Battery 

(a) The unit shall be equipped with a commercially available 
rechargeable battery, easily replaced in the field. 

(b) The battery cover shall be removable without tools and secure 
under normal use. 

(c) Rechargeable battery life shall be at least 8 hours under normal 
anticipated operating conditions. 
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8.4.2 PFTP Cradle 

The contractor shall provide a cradle style battery charger for the PFTP. 
The battery charger shall provide a regulated charge that maximizes 
battery life and charges PFTP batteries, at minimum, within one shift. 

8.4.3 Vehicle Charger 

The Contractor shall provide a charger suitable for mounting in a 
Paratransit or Vanpool vehicle with a standard automotive 12VDC 
cigarette lighter connection. 

6.111-8.5 Data Exchange Requirements - Portable FTP 

Data exchange requirements described in Section 6.III-3.6.1 (a) are replaced by the 
following: 

(a) Subject to the availability of suitable communications connections, the PFTP 
shall be able to share the same DACS as the Stand Alone FTP’s installed at 
Sound Transit rail platforms or DACS utilized for bus services by other 
Agencies. 

(b) The PFTP shall include and Ethernet interface for connection, 
directly or via the 4 unit cradle to the DACS, or to an existing modem. An 
Ethernet connection to the 1 unit cradle shall be provided through and 
optional Ethernet cable adaptor, (c) Depending on the option exercised 
by an Agency, the PFTP shall be supplied with an 802.11 wireless 
radio/network interface card for all wireless connections to the WDOLS at 
rail stations, transit bases, and at WSF and Kitsap Transit marine 
tenninals, or with an external modem for connection using dial-up 
telephone lines. 

(d) The PFTP, through maintenance mode or other operational mode, shall 
include functionality to switch between the Ethernet and 802.11 wireless 
connections. 

(e) Unless directed otherwise by an Agency for its specific application (e.g. 
Kitsap Transit), all communications shall be automatically initiated and 
completed. Communications for Kitsap Transit PFTP’s (and potentially 
PFTP’s for other Agencies, depending on the application) shall be 
initialized manually via the use of a button or screen icon and completed 
automatically. 

(f) In the event of an incomplete data transfer, the PFTP shall resend all data 
during the next connection. 
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(g) For mobile applications, all communications shall be through the supplied 

wireless communications interface or module. The supplied vehicle 
cradle/mount shall be used only for battery charging. 

6.MI-8.6 Additional Security Requirements - Portable FTP 

The Agent or authorized operator shall be required to enter a PIN to activate the 
PFTP and select the required route or service the PFTP is used on. 

(a) PFTP shall generate a record of the sign on/off. 

(b) The sign on/off log shall be transferred to the clearinghouse central system 
daily. 

6.MI-8.7 Environmental Requirements - PFTP 

Environmental requirements as listed in Figure III-3.2 are modified for the PFTP as 
follows: 

(a) Temperature range: +32°F to +110°F operating. 

(b) Humidity: 5%-80% relative humidity, non-condensing. 

(c) Minimum IP Rating: 65. 
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6.111-9 Stand-Alone Fare Transaction Processor 

6.MI-9.1 Subsystem Description - Stand-Alone FTP 

Stand-Alone FTPs (SAFTP) (DR 106) shall be ruggedized devices installed at Sound 
Transit Stations, and King County Metro and Community Transit bus rapid transit 
(BRT) stations and stops, and shall be designed for pedestal or wall mounting. Two 
SAFTP configurations shall be supplied: 

1. Configuration 1: An SAFTP equipped with zone/destination buttons for Sound 
Transit (DR 106.01). Passengers will select the number of zones of travel prior to 
presenting the fare card for payment. 

2. Configuration 2: An SAFTP with no button that supports either “tagon/tag-off’ 
operations, or “tag-on” only operations. 

At a minimum, the SAFTP shall consist of the modules listed in Figure III-9.1. 

Figure 111-9.1 

FTP CONFIGURATION SUMMARY 


Modules 

Stand-Alone 

FTP 

* Central Processing Unit 

X 

* Contactless Card Interface 

X 

* Customer Display/Indicator 

X 

Power Supply 

X 

Ethernet communications port (for 
network connection to a DAC) 

X 

Pedestal/wall mount bracket 

X 

Selection Buttons 

X (Configuration 1) 


“X” denotes module required by Contract 
* Module described in Section 6.III-3 


6.MI-9.2 Functional Requirements - Stand-Alone FTP 

The following functional requirements supplement those stated in Section 6.III-3.2. 

(a) Log-on from Agency personnel shall occur via a log-on smart card, through a 
command issued through the DACS (to activate all FTPs at a station).. 

(b) Zone selection buttons (Configuration 1) shall allow a customer to select a 
destination zone. The SAFTP shall calculate the fare based on the origin and 
destination zones or stations. 

(c) SAFTP (Configuration 1) shall be supplied with up to 10 zone selection 
buttons. The final number of zone selection buttons shall be determined at 
PDR (CDRL 2). 


Contract 229944 


6.111-94 


April 29, 2003 





















Stand-Alone Fare Transaction Processor 


Division III 


(d) The SAFTP shall support peak and off-peak fare pricing based on time of day 
and day of week. 

(e) SAFTP’s shall be configured for either “tag-on/tag-off ’ operation or “tag-on” 
operations only, depending on the service operated on and Agency 
preferences. 

(f) The location identification and the agency (which indirectly selects the “tag- 
on/tag-off’ or “tag-on” mode) shall be configured during commissioning of 
the device. 

(g) For tag-on/tag-off operation, the SAFTP shall deduct an initial fare (for stored 
value operation) upon tag-on, and provide a credit back to the card upon tag- 
off. For pass-products, tag-ons and tag-offs shall be registered for the purpose 
of ridership data collection, but no fare shall be deducted. 

(h) For tag-on only operation, a default fare shall be charged for stored value at 
the time of tag-on, with the amount dependant upon the fare table in effect and 
customer fare basis infonnation (e.g. adult/concession fare category and any 
preferred zone presets). For pass products, a tag-on shall be registered for the 
purpose of ridership data collection but no fare shall be deducted. 

(i) Data shall be written to the card as follows to support inspection using 
Portable Fare Transaction Processors (PFTP’s): 

i. For tag-on/tag-off operation, the card status shall be set to 
“tagged in” or tagged out” depending on the action that has 
occurred, and PFTP devices shall read this status to 
determine fare payment status. 

ii. For tag-on only operation, the fare payment transaction 
details shall be recorded on the card. The PFTP devices 
shall read these transactions details to detennine fare 
payment status. 

(j) Transfer rules shall be as follows: 

i. Transfers from a tag-on/tag-off transit service to a tag-on 
only transit service shall result in the applicable fare being 
on both services, subject to transfer rules in effect, 
regardless of whether or not the tag-off occurred on the 
first service. 

ii. Transfers from a tag-on service to either another tag-on 
service (at an SAFTP or OBFTP), or to a tag-on/tag-off 
service, shall result in the applicable fare being paid on 
both services, subject to transfer rules in effect. 
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iii. If a tag-on occurs on a BRT SAFTP and the customer also 
tags on to an OBFTP on a bus servicing the route upon 
boarding, this shall be treated as an intra-service transfer 
with zero fare deducted but both transactions recorded. 

6.111- 9.3 Performance Requirements - Stand-Alone FTP 

The minimum throughput rate for SAFTPs shall be 45 transactions per minute. 

6.111- 9.4 Physical Requirements - Stand-Alone FTP 

9.4.1 Dimensions and Layout 

A sample mockup of each SAFTP configuration and its mounting shall be 

demonstrated at time of PDR for each mounting location. (DR 106.01 and 

106.02) 

9.4.2 Structural Features 

(a) The SAFTP pedestal shall be constructed of 14 gauge stainless 
steel. 

(b) The wall mount shall be designed for outdoor installation at an 
unattended site, and shall include protection against removal or 
vandalism 

(c) The structural design shall be such that a force of 250 pounds 
applied in a horizontal plane at the topmost point of the SAFTP in 
any of the four mutual sides shall not result in dislodging of the 
SAFTP, pedestal or wall mount (where installed by the 
Contractor), and shall not bend or buckle the SAFTP, pedestal or 
wall mount. 

9.4.3 Keypad (zone selection buttons) 

The keypad/zone selection buttons shall meet the following requirements: 

(a) All keys or buttons shall have a 10 year service life in normal 
operation, regardless of number of actuations. In the event that a 
key or button fails before the 10 year service life, it shall be 
replace at no cost to the Agencies per Section 4.1 of Exhibit 14 of 
the Contract provided such failure does not constitute an Agency 
responsibility as defined in Section 4.2 of Exhibit 14. 

(b) The keypad shall be designed to be water and liquid resistant. 
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6.MI-9.5 Data Exchange Requirements - Stand Alone FTP 

(a) SAFTPs shall include an Ethernet interface with an RJ45 connection for wired 
connection to a DAC. 

(b) The SAFTP shall include capabilities to be connected to a PC through a 
standard RS232 port for diagnostic purposes. 

(c) The Contractor shall provide the software for a PC that allows the use of a PC 
keyboard to operate the SAFTP and PC monitor to display the card data. This 
connection from the SAFTP will be provided via an auxiliary serial port that 
is sealed within the SAFTP mounting pole or wall cradle and accessible at a 
remote location within visual range of the SAFTP. 

(d) SAFTPs supplied for WSF shall include a standard serial interface, designed 
for future connection to WSF’s new point of sale system. The Contractor 
shall provide an Interface Control Document (DR 106.02) fully describing this 
interface. 

(e) SAFTPs and associated DACs installed at Sound Transit rail stations shall 
communicate through Sound Transit’s existing TVM communications 
network. 

(f) SAFTP’s for BRT installations shall communicate via an Agency-supplied 
communications network to a designated DAC. 

6.111-9.6 Installation Requirements - Stand-Alone FTP 

9.6.1 Contractor Installed Mounting Hardware 

(a) SAFTPs shall be designed to be installed freestanding on a pedestal or wall 
mounted. 

(b) The Contractor shall furnish to the Contract Administrator and affected 
Agency with bolt pattern mounting requirements, foundation designs, and 
electrical/communications construction and connection details. 

(c) The Contractor shall furnish one (1) set of anchor bolts and all mounting 
hardware, including mounting or pedestal base if required, for each SAFTP 
furnished under this contract. 

(d) The Contractor shall be responsible for mounting the SAFTPs with bolts or 
other means to a concrete surface. Each unit shall be properly leveled, 
accommodating station platform slopes of up to 2 % traverse and 2.4% 
longitudinal, prior to being permanently installed. 

(e) Removal of SAFTPs shall be possible without damage to concrete or 
attachment devices. The attachment devices shall not be exposed to the 
public after the equipment is installed. 

(f) Conduit, power and communications cables leading from the power and 
communications sources to the junction box shall be installed by the Agency. 
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Connections from the junction box to the SAFTP shall be the responsibility of 
the Contractor. 

(g) The Contractor shall install the SAFTPs over the junction boxes, providing 
bottom entry of power and communication lines such that no wiring or 
cabling is exposed outside the SAFTP cabinet or base, and the Contractor 
shall make final connections (plug-in) to power and communications. 

(h) The Contractor shall perform commissioning/commissioning test services of 
devices as well as installation testing services. 

9.6.2 Agency Installed Mounting Hardware 

(a) SAFTP’s shall be designed to be installed freestanding on a pedestal or wall 
mounted. 

(b) The Contractor shall furnish to the Contract Administrator and affected 
Agency with bolt pattern mounting requirements, foundation designs, and 
electrical/communications construction and connection details. 

(c) The Contractor shall furnish one (1) set of anchor bolts and all mounting 
hardware, including mounting or pedestal base if required, for each SAFTP 
furnished under this contract. 

(d) The Agency shall be responsible for attaching the mounting hardware with 
bolts or other means to a concrete surface (pedestal) or wall (wall mount box). 
Each unit shall be properly leveled, accommodating station platform slopes of 
up to 2% traverse and 2.4% longitudinal, prior to being permanently installed. 

(e) Conduit, power and communication cables leading from the power and 
communication sources to the junction box shall be installed and tenninated 
by the Agency. 

(f) The Agency shall be responsible for fitting SAFTP to SAFTP pole or SAFTP 
wall mount enclosure with three bolts supplied by ERG. 

(g) The Agency shall machine holes into base plates to accommodate surface 
mount conduit where preferred and shall fit base covers to SAFTP pole where 
required. 

(h) The Contractor shall perform commissioning/commissioning test services of 
the Agency installed devices as well as installation testing services. 
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6.111- 10 Integration with Sound Transit TVMs 

6.111- 10.1 Subsystem Description -TVM Integration 

Sound Transit has implemented new ticket vending machines (Scheidt and Bachmann 
model FA 2000/TS [ touch screen]) with the capability of being retrofitted with RFCS 
smart card equipment. 

The Contractor shall be responsible for supplying RFCS hardware, software and 
services as described herein to support integration of RFCS smart card functionality 
into the TVM identified above. Specific Contractor responsibilities include: 

(a) The supply of RFCS smart card read/write equipment including reader/write 
devices, housings, mounting brackets, mounting hardware, and cabling as 
agreed with Sound Transit and the TVM Contractor (Scheidt & Bachmann) to 
interface with Sound Transit TVM’s and provide the functionality as 
described herein (DR 107). 

(b) Supporting the integration of RFCS smart card read/write equipment with the 
credit/debit card, cash acceptance, and customer display functions of the TVM 
(DR 107.01) as provided by the TVM Contractor. 

(c) Integrating supplied smart card equipment with the ST communications 
network to provide connectivity to RFCS clearinghouse. 

(d) Providing support to Sound Transit and the TVM Contractor to confirm and 
document the preferred design, identify changes to TVM hardware, software 
and communications (including the customer interface) required to support 
RFCS functionality, and support system development and testing. 

6.111- 10.2 Functional Requirements - TVM Integration 

10.2.1 Card Interface Module 

(a) The Contractor shall provide an RFCS card interface module. 

(b) Fare cards shall be revalued using the card interface module. 

(c) The fare card interface shall use contactless technology. 

(d) The Contractor shall provide features in the card interface module 
for maintaining data integrity and completing the transaction 
through contactless interface between the card interface module 
and card, and between the card interface module and RFCS 
clearinghouse. 
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10.2.2 Operation and Functional Requirements 

(a) The Contractor shall provide RFCS smart card hardware, software, 
and interfaces to: 

iii. Allow customers to conduct an RFCS smart card balance 
inquiry 

iv. Allow customers to add value and fare products to their 
RFCS smart cards. 

v. Allow RFCS smart card stored value to be used for the 
purchase of non-smart card fare media. 

vi. Support smart card dispensing at Ticket Vending 
Machines. 

(b) The TVM (supplied by the TVM Contractor) will provide 
customer interface, payment, and card dispensing functionality. 
The Contractor shall provide RFCS equipment, messaging, 
libraries, drivers, and documentation as required to support 
integration with customer, payment and card dispensing 
subsystems of the TVM by the TVM Contractor. 

10.2.2.1 Transaction Selection 

RFCS smart card hardware and software shall provide messaging and 
interfaces to support selection of the following at the TVM: 

(a) Transaction type, such as add value or card value/history inquiry. 

(b) Method of payment. 

(c) Desires Agency, when more than one Agency applicable. 

(d) Whether to proceed without a receipt, regardless if a receipt is 
unavailable. 

(e) If a customer presents a fare card without first selecting a 
transaction type, the Display shall default to an inquiry response 
screen. 

i. Withdrawal of the card without any further action shall cause 
the unit to revert to standby for the next transaction. 

ii. Selecting a transaction after card presentation shall interrupt 
the balance inquiry and proceed to next logical step in executing 
the selected transaction. 
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(f) Purchase of non-smart card fare products. 

(g) Dispensing of a pennanent smart card. 

10.2.2.2 Card Balance Inquiry 

Functionality and interfaces shall be provided to respond to the following 
balance inquiry requests, and return information to the TVM for display 
via the customer interface: 

(a) Stored value balance on the card. 

(b) Active passes on the card, by Agency, including validity period or 
expiration as applicable. 

(c) Active multi-ride products on the card, including remaining rides. 

10.2.2.3 Stored Value Load 

Functionality and interfaces shall be provided to allow customers to add 
stored value to the RFCS smart card, using any payment mechanism 
accepted by the TVM. Functions to be provided include: 

(a) The RFCS hardware and software shall provide messages 
indicating the starting balance (current value) on the card for 
display on the TVM customer interface. 

(b) The RFCS hardware and software shall support addition of stored 
value in an amount selected by the customer through the TVM 
customer interface. 

(c) The RFCS hardware and software shall execute a stored value load 
only after the TVM has accepted/approved payment. 

(d) The RFCS hardware and software shall confirm that the load has 
been executed, and provide messaging to the TVM to display the 
updated stored value balance on the TVM screen. 

(e) The RFCS hardware and software shall provide messaging to the 
TVM and RFCS clearinghouse if a load has failed, and shall 
provide functionality for the customer to re-attempt the load 
without additional payment. 
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10.2.2.4Pass or Multi-Ride Load 

RFCS functionality and interfaces shall be provide to allow customers to 

add, through the TVM and its interfaces, pass and multi-ride products to 

the card using any payment mechanism accepted by the TVM. Equipment 

and software shall support the following: 

(a) For pass or multi-ride transactions, the customer shall select the 
Agency and desired fare product(s) to be purchased. 

(b) The RFCS hardware and software shall read the reduced fare 
privileges encoded on the card, and automatically determine 
whether a discount is available for the requested type of fare at the 
relevant Agency (e.g. youth monthly pass). If so, messages shall 
be returned to the TVM. 

(c) If a multi-ride product is already loaded on the card but has not 
been exhausted, functionality shall be provided to display of the 
starting balance (remaining rides) on the card for display on the 
TVM customer interface. 

(d) Products shall be loaded only after the TVM has 
accepted/approved payment. 

(e) The RFCS hardware and software shall confirm that the load has 
been executed, and provide messaging to the TVM to display the 
updated stored value balance on the TVM screen. 

(f) The RFCS hardware and software shall provide messaging to the 
TVM and RFCS clearinghouse if a load has failed, and shall 
provide functionality for the customer to re-attempt the load 
without additional payment. 


6.111- 10.3 Performance Requirements - TVM Integration 

(a) The card reader shall have a reliability of at least 50,000 mean transactions 
between failures on a reader processing at least 10,000 transactions per 
month. 

6.111- 10.4 Physical Requirements - TVM Integration 

(a) The Card Interface Module and any major subassemblies shall have a 

pennanently attached label inscribed with a unique serial number and part 
number prominently located on the subassembly. 
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(b) The card interface module and any major subassemblies shall be modular and 
easily replaceable with like units. 


6.111-10.5 Environmental Requirements - TVM Integration 

RFCS equipment shall be designed to operate within the TVM enclosure. When used 
as part of the TVM, it will operate to the following external environmental conditions 
provided in Figure III-10.1. 


Figure 111-10.1 


OPERA1 

riNG ENVIRONMENT 


RFCS Equipment 

Temperature Range: 

+14°F to +99°F, Ambient 

Humidity: 

5% - 100% RH 

Shock: 

Up to 5g horizontal 

Vibration: 

Same as section 

EMI: 

Same as section 

Other (dust, grit, rain and 
saltwater protection): 

• Maximum 3 inches of rain in 24 hours 

• Maximum 14 inches snowfall in 24 hours 

• Wind (70 MPH gusts) 

• IP55 rating. 


6.111- 10.6Data Exchange Requirements - TVM Integration 

(a) RFCS equipment shall communicate to the clearinghouse system through a 
network to be provided by Sound Transit. An Ethernet connection will be 
provided to the RFCS equipment. 

(b) Under normal operations, all data transmission shall be initiated 
automatically. 

6.111- 10.7 Installation Requirements - TVM Integration 

(a) The Contractor shall provide the Contract Administrator with a detailed 
installation and mounting requirements, including electrical and 
communications connection requirements (DR 107.04). 

(b) The Contractor shall identify requirements for any required TVM software or 
hardware modifications. 

(c) The Contractor shall reasonably assist the TVM vendor with determining how 
to best locate, install and connect RFCS hardware. 


Contract 229944 


6.111-103 


April 29, 2003 




















Integration with Sound Transit TVMs 


Division III 


6.111-10.8 Testing Requirements and Procedures -TVM Integration 

(a) The Contractor shall be responsible for testing RFCS hardware and software 
supplied using a suitable test harness within a test environment at the 
Contractor’s facilities. A TVM will not be shipped to the Contractor’s 
facilities and all testing will be done using the test harness. 

(b) A minimum of 10,000 transactions shall be conducted. 

(c) Transactions shall be divided evenly among all possible card purchase and 
load transactions of which the device is capable. 

(d) The transactions shall test all possible payment combinations f as feasible in 
the test environment. 

(e) Stored value amounts, stored pass and multi-stored ride types and amounts, 
and fare amounts shall be representative of those expected to be employed in 
the RFCS. 

(f) Detailed information regarding the transaction types, values, and payment 
methods to be used in the cycling test shall be included in the Detailed Test 
Procedures and subject to Contract Administrator approval. 
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6.111- 11 Customer Service Terminal (CST) & Wireless Portable Customer 

Service Terminal (WPCST). As specifically noted, the below 
requirements support the CST Application loaded on both device 
types, or, if the requirement supports only one of the devices, the 
device type is called out seperately as either the CST and WPCST 

6.111- 11.1 Subsystem Description - CST 

The CST (DR 108) shall provide the capabilities necessary for supporting RFCS 
through the Agency’s customer service offices and for mail and phone inquiries and 
for remote customer outreach perfonned in the field using the WPCST. The 
Customer Service Terminal (CST) shall at a minimum provide the following 
customer service capabilities: 

(a) Initialize and issue all types of fare cards. 

(b) Encode personal data onto fare card and record it in the RFCS database by 
creating a new customer record (ORCA Account). 

(c) Using the CST, process, at a minimum, payment by cash; credit card and debit 
cards, electronic vouchers, checks, requisitions and purchage orders. Revalue 
fare cards with fare value from any Agency. 

(d) Using a WPCST, process, at a minimum, payment by cash, electronic 
vouchers, checks, requisitions and purchase orders. Record the credit and 
debit card transaction authorization code and the last four (4) digits of the 
credit card. Revalue fare cards with fare value from any Agency. 

(e) Process refunds and replace fare cards. 

(f) Show remaining value and pass status of card. 

(g) List the last ten (10) fare card transactions. 

(h) Block fare cards. 

(i) Unblock fare cards that have been blocked. 

(j) Provide a transaction history on each fare card by accessing the clearinghouse 
database, and ability to print duplicate receipts at the time of the sale. 

(k) Print receipt for each transaction or inquiry of remaining value. 

(l) Enroll customers in Autoload program. 

(m) Disable a customer’s participation in the Autoload program. 

(n) Register a fare card. 
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(o) Unregister a non-youth or non-RRFP fare card. 

(p) Support the sales of non-RFCS products. 

6.111-11.2 Functional Requirements - CST 

(a) The CST application shall provide a means of quickly selecting “express 
transaction” types for the most common types of card values loaded. 

(b) The CST application shall be able to read and encode on the fare card for the 
initial sale and subsequent revalue actions any value up to the maximum limit, 
load any pass or type of ride for any Agency. 

(c) The Agency personnel shall be able to initiate the type of transaction by 
selecting the type of value to be loaded for a selected Agency, and origin- 
destination or zones if applicable. 

(d) Agency personnel shall be able to cancel a transaction at any point during the 
purchasing process prior to the initiation of the transfer of value to fare card. 

(e) The CST shall prompt Agency personnel to select the applicable payment 
type. 

(f) A transaction receipt may be printed at the CST upon request for any type of 
payment except when processing credit or debit transactions at a WPCST. 
CSTs for WSF shall print receipts for every transaction by default. 

(g) Upon the completion of the transaction selection, the CST shall calculate and 
display the amount due for the selected card value loaded on the operator 
display as well as the external customer card interface unit display. 

(h) On the same CST and shift that the original transaction occurred, the CST 
application shall be able to reverse the value that has been loaded on a fare 
card and provide an audit trail of who reversed it, including time date and 
tenninal ID. 

(i) The CST Application shall provide mid-shift and end of shift accounting. 

(]) At the end of a sales day, the CST Application shall provide a daily summary 
report indicating total sales, revenue collected, passes sold, amounts of 
refunds issued and the number of refunds. 

(k) The daily orders received and orders filled shall be transferred to and from the 
clearinghouse at least once a day per Agency for the CST. For the WPCST 
such action will vary based on Agency provide network connectivity available 
to the device. 

(l) The CST shall support telephone, Internet and mail order services. The 
WPCST shall support Wireless Internet services only. 
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i. All CST telephone, Internet and mail orders filled shall be tracked on 
a daily basis. 

(m) The CST Application shall provide provisions for entering customer 

information including name address, phone number and ID number. 

i. The CST shall have functionality to generate customer numbers. 

ii. The CST shall have functionality to utilize Agency-specified 
customer numbers. 

iii. The CST shall have the capability to track transactions by customer 
number, transaction numbers, or card serial numbers. 

iv. The CST shall allow Agency personnel to override the standard card 
fee, and track and report each override event. 

v. All CSTs, revalue and infonnation devices/systems shall reference 
the same customer identification information record, to avoid 
duplication of records for a specific customer. 

(n) The CST Application float shall be the same for the CST and WPCST. 

(o) The CST Application shall record payment method or methods for each sales 
transaction. 

(p) The CST shall be capable of operating commercial off-the-shelf software such 
as word processing and spreadsheet programs concurrent with CST functions. 

(q) CST peripherals shall be modular. 

(r) The Agencies shall have the option of procuring: 

i. A fully configured CST designed for over the counter service. 

ii. The CST components as described in Exhibit 9, Price Schedule. 

iii. The WPCST commercially available laptop computer. 

(s) The CST via the MS Retail Application shall provide a report identifying 
inventory quantities on hand, quantities sold, and quantities added during the 
day. 

(t) The CST shall provide the ability to override card printing requirements when 
issuing a Regional Reduced Fare Permit card. 

11.2.1 Cash Sales 

(a) The CST Application shall recognize cash as the default payment 
method. 

(b) The CST operator shall enter the amount received into the CST 
Application using the keyboard (the default value, obtained by 
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pressing enter, shall be the amount due from the customer for the 
current transaction) and the CST Application shall encode the fare 
card. 

(c) In the case of overpayment, the CST Application shall calculate 
the change due to the customer, display the corresponding amount 
on the CST operator interface screen. 

(d) Cash change shall be provided by the operator via the CST cash 
drawer. 

11.2.2 Check, Purchase Order, or Money Order Sales 

(a) Upon receipt of a money order, purchase order (PO) or check for 
payment, the operator shall either scan the payment through the 
electronic check reader or manually enter the payment number into 
the CST Application using the keyboard. 

(b) The CST Application shall provide the following features when 
processing checks and POs: 

i. The CST Application shall prompt Agency personnel to 
enter current ID, such as drivers license and expiration 
date. 

ii. The CST Application shall have the ability to endorse 
checks and POs electronically listing the deposit 
information on the back of the payment, at the time the sale 
is made. 

iii. The system shall have the ability to create a bad check file. 

(c) The check number shall be verified against the “bad check” and 
“accepted corporate check/purchase order” files resident in the 
CST Application. 

(d) For POs or other billing accounts, the CST Application shall 
record as a minimum: 

i. Company or organization 

ii. Billing address 

iii. Payor contact 

iv. Payor reference number (alphanumeric) 

v. Agency reference number (alphanumeric) 

vi. Notes 

vii. Special handling instructions 

viii. Ship-to address 
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ix. Payor telephone number 

(e) Upon local verification of the check/PO at the CST, the CST 
Application shall send a message to the clearinghouse requesting 
check transaction authorization. 

(f) Such check transactions shall be processed in a manner similar to 
electronic payment transactions. Upon receipt of authorization, 
the CST Application shall notify the Customer Service 
Representative (CSR) of the check/PO authorization number and 
transfer value to the fare card. 

(g) Bad check and accepted corporate check/PO files shall be updated 
at the clearinghouse and downloaded on a daily basis to the CSTs 
or as Agency network connectivity allows for the WPCST. 

(h) Check transaction processing shall be conducted in accordance 
with the requirements of the authorizing financial 
institution/ network. 

11.2.3 Telephone, Mail and Internet Fulfillment and Customer Service 

(a) The CST Application shall include functionality to provide 
telephone, mail and Internet Customer Service and Support in a 
“card not present” environment. 

(b) The CST Application shall include functionality to provide 
Institutional Program customer service in a “card not present” 
environment. 

(c) The CST Application shall generate local card fulfillment orders 
for Internet requests processed through the RFCS Internet Website 
operated by the Contractor on behalf of the Agencies. 

(d) Internet website orders shall be routed to an Agency or Agencies 
as defined by the Contract Administrator. 

(e) The CST Application shall include functionality to create packing 
slips and mailing labels. Print size and font type shall meet United 
States Postal Service (USPS) standards. 

11.2.4 Electronic Payment (Credit/Debit Card) Transactions 

(a) The customer shall perform the following steps using an external 
customer card interface unit: 

i. Swipe the card to be used for payment 

ii. Select the type of electronic payment, i.e., credit or debit 
card 
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11.25 


11 . 2.6 


iii. Enter the corresponding account PIN number and press 
“OK” (debit transactions only) 

iv. Press “OK” to accept the amount to be charged to the 
corresponding account 

(b) The CST shall immediately receive the account information read 
from the card and the CST operator shall forward the transaction 
authorization request to the clearinghouse by depressing a hot key 
on the keyboard. 

(c) The remainder of the transaction shall be processed in a manner 
similar to that of electronic payment transactions at a TVM, with 
the exception that a duplicate transaction receipt with a signature 
line shall be automatically issued by the CST for all credit card 
transactions. 

(d) The signed receipt shall be retained in the CST cash drawer for 
transaction clearing purposes. 

(e) The CST shall contain provisions for the reversal of a credit/debit 
transaction when the transaction is canceled prior to ticket issuance 
or card encoding. 

(f) The processing of all credit and debit transactions shall conform to 
the requirements of ISO 8583. 

Electronic Payment (Credit/Debit Card) Transactions (WPCST) 

(a) The CST Application on the WPCST shall be modified to only 
recognize a request to pay by credit card. 

(b) The CST Application on the WPCST shall be modified to only 
recognize a request to pay by debit card. 

(c) The CST Application on the WPCST shall record the card type 
(MC, Visa, Debit), authorization code, and the last 4 digits of the 
card number used. 

Fare Card Inventory Management 

(a) When a new fare card is initialized, and issued the CST 
Application shall capture the serial number of the fare card for the 
clearinghouse. 

(b) The CST Application shall automatically track the card inventory 
of the Agency against the clearinghouse card inventory 
management file as fare cards are sold and initialized. 
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11.2.7 Customer Service Agent Sign-On/Off 

(a) For an Agent to sign on, the following procedure shall be followed. 
Additionally, the Agent shall be required to unlock the CST cash 
drawer with a key to gain access to the drawer. The Contractor 
shall provide to the Contract Administrator five (5) sets of all CST 
keys a minimum of 60 days prior to the delivery of the first CST. 

(b) Agent enters their PIN. 

(c) Agent tags their valid operator smart card. The CST Application 
shall compare the PIN encoded on the smart card with the PIN 
entered and the CST shall only be operable when the two match. 

(d) The CST Application shall be able to track incorrect Operator 
sign-on attempts, and shall block the Operator card after a 
configurable number of failed attempts. 

(e) The CST Application shall automatically record all operator sign- 
on and sign-off attempts. Locking the CST cash drawer shall have 
no effect on Agent’s data. If an Agent has not signed off, the sign- 
on of a subsequent Agent shall cause an automatic sign-off for the 
first operator without loss of any data. 

(f) The Agent shall be able to key in the working cash fund that is 
available at the start of their shift and to have the CST Application 
keep a running balance throughout the shift by accounting for cash 
received for any cash sales. 

11.2.8 CST Systems Administration Mode 

Through commands entered using the Agent interface such as the 

keyboard or touch-screen, authorized maintenance and/or revenue service 

personnel shall be able to place the CST Application into Systems 

Administration Mode. 

(a) The CST Application shall have a maintenance and systems 
administration mode function. 

(b) When in Systems Administration Mode, the customer interface 
display shall read “Out-of-Service” and the operator interface shall 
be used to enter commands, perform queries, and receive 
information from the machine on both the monitor screen and on 
audit. 

(c) The CST Application shall not be capable of loading value onto a 
smart card when in the maintenance mode. 
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(d) The CST Application shall return from the Systems Administration 
Mode to revenue service after servicing. 

11.2.9 CST Training Mode 

Through commands entered using the Agent interface such as the 

keyboard or touch-screen, authorized Agency personnel shall be able to 

place the CST Application into Training Mode. 

(a) In Training Mode, the CST Application shall simulate nonnal 
operation including actual display messages 

(b) In Training Mode the CST Application shall on be capable of 
loading value onto the cards issued as special Training Cards, and 
that these training card cannot be used with the operational system. 

(c) A record from the time the CST Application entered Training 
Mode to the time returned to normal operation shall be created and 
transferred to the clearinghouse central system during the next 
scheduled data offload cycle. 

11.2.10 Non-RFCS Sales 

(a) The CST Application shall have functionality to process, record 
and report the sales of non-RFCS products. 

(b) The CST Application shall have the ability to track the inventory 
of used, unused, sold, and on-hand non-RFCS products in the 
system by using barcode or manually entered serial numbers. 

(c) The CST Application shall provide local inventory and revenue 
reporting of the sale of non-RFCS products. 

(d) The CST Application shall provide a combined report of all 
revenue collected and payment methods used to support single 
deposit. Revenue reports shall distinguish between RFCS and 
non-RFCS product sales, amounts and payment methods. 

6.111-11.3 Performance Requirements - CSTand WPCST 
11.3.1 Reliability 

(a) The following reliability rates, Mean Transactions Between Failure 
(MTBF), shall apply for a high transaction volume environment: 
10,000 MTBF. 

(b) Reliability shall be measured as follows: 
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i. For the CST, the reliability shall be 5000 Mean 
Operating Hours Between Failure (MOHBF) in a low 
transaction volume environment. 

ii. For the WPCST, the reliability shall be 720 Mean 
Operating Hours Between Failure (MOHBF) in a low 
transaction volume environment. 

(c) High and Low Volume Transaction environments are defined in 
Section 6.Ill-1.5.1 (a) and (b). 

(d) Any component or assembly within a CST that fails more than two 
(2) times per month shall be replaced with a new component or 
assembly. 

i. If the new component or assembly experiences the same 
failure rate, the Contractor shall be responsible to initiate 
an investigation to detennine the cause. 

ii. Alternatively, failures shall average no more than two (2) 
failures per device type every 90 days for the total 
population for each type of CST in revenue service. 

11.3.2 Availability (CST) 

Availability shall be measured at a minimum for the following: 

(a) The CST shall be available to conduct a transaction 99.73% [a a 
(second sigma)] during operating hours. 

(b) Credit or debit card authorization shall be available as specified in 
Section 6.Ill-1.5.2, “Availability.” 

(c) CSTs shall be available to transmit data upon request to the 
clearinghouse 99.73% [a a (second sigma)] during the scheduled 
time periods for these activities (refer to Section 6.III-1.5.2 
“Availability”). 

(d) Contractor shall provide a detailed plan that describes the 
methodology of capturing and processing the data to be used to 
measure availability (CDRL 39). 

11.3.3 Accuracy 

(a) Accuracy shall be measured as shown below. Accuracy for 
all types of electronic payments is defined as the mean ratio of the 
transactions value recorded by the device as evidenced by the 
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transactional data recorded to the actual transaction records 
received and processed by the clearinghouse. 

i. For the CST, the electronic payments functions 
shall have an accuracy rate of 99.73% (a a sigma). 

ii. For the WPCST, the electronic payment functions 
shall have an accuracy rate of 99.9% to 100.01%. 


(b) The cash transaction functions shall have an accuracy rate 
of 99.5%. 

Accuracy for the cash processing functionality is defined as the 
mean ratio of the moneys recorded as evidenced by the audit 
receipts produced by the device to the actual moneys in the bill and 
coin vaults as counted. Cash reconciliation differences attributable 
to beginning inventory shortages or loading errors shall be 
excluded. Differences attributable to counting errors shall also be 
excluded. Reconciliation differences shall be reported by relevant 
device within 24 hours. 

6.111-11.4 Physical Requirements - CST 

(a) The full-function CST shall contain the modules listed in Figure III-11.1. 

(b) Agencies shall have the option of procuring CSTs with any combination of 
peripherals for mail, telephone or other applications that may not require all 
peripherals. 

(c) Agencies shall have the option of procuring additional peripherals as 
illustrated in Figure III-11.2 
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Figure MI-11.1 
CST MODULE SUMMARY 


Module 

CST Reference 

WPCST Reference 

CST CPU (DR 108.01) 

X 


WPCST Ruggedized CPU 


X 

Magnetic Card Reader (DR 108.02) 

X 


PIN pad (DR 108.03) 

X 


Agent Display (DR 108.04) 

X 


Customer Display (DR 108.05) 

X 


Fare Card Reader/Writer (DR 108.06) 

X 

X 

Keypad/board (DR 108.07) 

X 


Printer-Receipt (DR 108.08) 

X 

X 

Cash drawer (DR 108.09) 

X 


Secure Access Module (SAM) (DR 108.12) 

X 

X 

“X” denotes module required by Contract 

Figure MI-11.2 


CST- 

ADDITIONAL MODULES 


Module 

CST Reference 

WPCST Reference 

Photo ID Equipment (DR 108.10) - 
camera & power supply 

X 

X 

Card Dispensing Module (DR 108.11) 

X 



11.4.1 Customer Service Terminal and Wireless Portabel Customer 
Service Terminal 

11.4.1.1 The Customer Service terminal shall consist of: 

(a) CPU, based on the latest generation of Intel or Motorola microprocessor or 
approved equivalent and shall be configured with sufficient memory, data 
storage, and appropriate communications to meet the functional requirements 
defined for the terminal. Unless otherwise required for the provision of drive 
bays or interface cards, the CPU shall be supplied in a mini-tower 
configuration. If a larger housing is required to accommodate additional drive 
bays or interface cards, the CPU shall be supplied in a tower configuration. 

(b) Full function keyboard or touch screen interface. 

(c) Minimum 17 inch standard PC active matrix LCD monitor. The monitor shall 
be readable in all ambient light conditions, including both day and night. The 
display shall be subject to the review and approval of the Contract 
Administrator (DR 108.04). Due to space constraints at customer service 
offices, some Agencies may require 15 inch LCD monitors in lieu of 17 inch 
monitors. This will be determined at Preliminary Design Review (CDRL 2). 
The CST shall be designed to operate with either a 15 inch or 17 inch 
monitor. 

(d) Default selections on the key board or touch screen shall be provided to speed 
up the transaction process for commonly used transactions. 
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(e) Receipt printer. 

(f) Locked cash drawer. 

(g) A customer display to provide the transactional information to the customer. 

(h) The CST interface shall be subject to Contract Administrator review and 
approval (DR 108.04). 

(i) Fare Card Reader/Writer. 

(j) Printer-Receipt 

11.4.1.2 The Wireless Portable Customer Service Terminal shall consist of: 

(a) Ruggedized laptop computer shall be configured with sufficient 

memory, data storage, and appropriate communications to meet the 
functionality requirements defined for the WPCST. 

(b) Printer-Receipt. 

(c) Fare Card Reader/Writer. 


Figure 111-11-3 
WPCST CPU Configuration 


Item 

Specification 

a. Processor 

Intel Core i5-2520M, 2.50GHz, 3MB Cache 

b. Memory 

4.0GB, DDR3-1333MHz SDRAM, 1DIMM 

c. Hard Drive 

250GB Hard Drive 7200RPM 

d. Serial Ports 

1 x RS232 

e. USB Ports 

5 ports (USB Hub) 

f. Keyboard and Mouse 

USB or wireless (optional) 

g. Network 

10/100Base-T Ethernet/WLAN (802.1 lb/g/n 

e. Power Supply 

100-240 VAC, output rating 250W 

f. Rugged Features & Testing 

MIL-STD 810G shock, vibration, temperature, altitude, 
and humidty 

IEC60529 IP5X for dust 
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g. Environmental Specification 


Operating Temp: 0 to 60 degrees C (32 to 140 degrees F) 
Storage Temp: -51 to 71 degrees C (-59 to 159 degrees F) 


Figure 111-11-4 


WPCST Required Software Components 


Peripheral Device Function 

(a) 

Windows XP 

3 rd Party Supplied 

(b 

) 

MS Retail v2.0 

3 rd Party Supplied 

(c) 

Trend Micro Enterprise Security for Endpoints 

Advanced 

3 rd Party Supplied 

(d 

) 

SQL Server 2000 CALs 

3 rd Party Supplied 

(e) 

Contractor CST Application 

Contractor Supplied 

Support Components/Device other than those supplied with peripheral device 

(f) 

Wireless Modem 

Supplied by service 
provider 


11.4.2 Customer interface Unit 

The customer interface unit shall consist of the following: 

(a) Customer data entry/PIN pad connected to the CST via a flexible 
cable. 

(b) The pad shall be a DES/UKPT encrypting numeric keypad for PIN 
entry. 

(c) EMV compliant magnetic stripe card reader. 

(d) Privacy hood or shield to protect the privacy of PIN code entry. 

(e) Display to prompt the customer and to indicate the amounts being 
charged to their credit or debit cards. The display shall indicate 
that PIN entries are being made with * but shall not record the 
characters being entered. 
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11.4.3 Cash Drawer 

The CST shall provide a uniquely keyed, lockable cash drawer attached to 
or detached from the CST unit. 

(a) The cash drawer shall be designed and constructed to be pry-proof 
to prevent unauthorized entry when closed and locked. 

(b) If a separate device from the CST, the cash drawer shall withstand 
a drop on any corner or side from a height of 2.5 feet onto a 
concrete floor when containing a full compliment of bills and 
coins. 

(c) The drop incident shall not cause the cash drawer to open and shall 
leave the drawer operational. 

(d) The drawer shall contain a removable subdivided tray for currency, 
coin, checks and other documents received by the operator. 

i. The tray shall have the capacity to separately store a 
minimum of 80 bills of each of 4 US currency 
denominations and a minimum of 60 coins of each of 5 US 
coin denominations (including SBAs, quarters, dimes, 
nickels, and pennies) in compartments sufficiently sized for 
these items. 

ii. The tray shall also contain two compartments of 4 inches 
by 6 inches and a minimum of 1 inch deep to accept paper 
documents. 

11.4.4 Receipt Printer 

The CST and WPCST shall include a Receipt Printer as an integral part of 
the device or as a stand-alone device that interfaces with the CST or 
WPCST through a standard communications port. 

(a) The receipt printer shall include a roll-type receipt paper feed a 
thennal printer. 

(b) Receipt infonnation shall be software programmable. 

(c) Each Receipt Printer shall be configured to print duplicate receipts 
with signature lines for credit card transactions. 

(d) Printed characters shall be in black print, smudge resistant when 
handled immediately by the operator or customer. 

(e) Receipt printing for any type of transaction shall take no longer 
than 4 seconds. 
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11.4.5 Photo Identification System 

The CST and WPCST shall include capabilities to print a photo on to 
special fare cards categories in support of the RRFP or other photo/ID 
programs. 

(a) 

The photo identification (ID) system shall consist of the following 
components: 


i. Digital camera. 

ii. Application software. 

iii. Card printer. 

iv. Card lamination unit, if required. 

(b) 

The photo ID system shall process and print the image on to the 
fare card at a maximum of five (5) minutes. 

(c) 

Once the printing process is completed the image shall be smudge 
proof and pennanent for the life of the fare card. The image may 
be laminated with a clear plastic sheathing as protection. 

(d) 

The photo ID system shall be able to operate on CST and WPCST 
hardware platforms. 

(e) 

A single photo ID system shall be accessible from multiple CSTs 
through an Agency’s network when operated in an Agency CSO. 

(f) 

For the WPCST, transfer of digital photographs from a digital 
camera in the field, and association of the photographs with the 
corresponding customer records. 

(g) 

For the WPCST, transfer captured data and images to the RFCS 
clearinghouse upon connection of the laptop computer to the RFCS 
network at the Agencies facilities. 

11.4.6 Card Dispenser 

(a) 

The card dispenser shall be capable of independently distributing 
two (2) different card products including the fare card and 
disposable fare card. 

(b) 

The card dispenser shall be housed in a secure, lockable housing. 

(c) 

A means shall be provided for keeping the card stock unexposed 
and secure at all times outside of card stock replacement actions. 

(d) 

Each card dispenser magazine shall be capable of holding a 
minimum 300 fare cards. 
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(e) The cards shall be dispensed in an automatic fashion upon the 
receipt of payment at the CST for a smart card sales transaction. 

(f) Dispensing time shall be one (1) second or less. 

6.111- 11.5 Electrical Requirements - CST 

In the event of a power interruption, a rechargeable dry or sealed gel cell battery 
source (or UPS) shall provide auxiliary power to the CST for a minimum of 10 
minutes of full operation. And at the end of the 10 minutes, complete the transaction 
in progress and allow for orderly shutdown of the CST, including transmitting all 
audit data and alarm conditions to the clearinghouse. 

6.111- 11.6 Environmental Requirements - CST and WPCST 

The CST and WPCST shall be designed to operate in the environmental conditions 
provided in Figure III-11.5. 

Figure 111-11.5 

OPERATING ENVIRONMENT 



Customer Service Terminal Standard 

Wireless Portable CST 

Temperature 

Range: 

Climate controlled office environment and 
WSF toll booths 

See Figure 111-11.3 (g) 

Humidity: 

Climate controlled office environment and 
WSF toll booths 

See Figure 111-11.3 (f) 

Shock: 

Minimum 20g non-operating, 2.5g 
operating. 

See Figure MI-11.3 (f) 

EMI: 

Applicable FCC requirements 

• Applicable FCC requirements 

• 3 rd Party equipment - 
Manufacturers’ EMI specifications 

Other (dust, grit, 

rain/water 

protection): 

Climate controlled office environment 

See Figure MI-11.3 (f) 


6.MI-11.7 Data Exchange Requirements - CST and WPCST 

(a) CST event and transaction data shall be transferred to/from the clearinghouse 
via a Agency provided communications network. 

(b) WPCST event and transaction data shall be transferred to/from the 
clearinghouse via the Agency’s communication network. 

(c) Data back-up features shall be included to maintain the integrity of all data 
stored in the CST Application in the event of system or component failure. 
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6.MI-11.8 Installation Requirements - CST and WPCST 

(a) The Contractor shall install and setup all elements of the CSTs in the 
designated customer service offices. 

(b) To the extent practical, the CST equipment shall be secured to prevent theft or 
damage. 

(c) The Contractor shall make all connections to power and communications, all 
connections between CST elements, and route all cables neatly and out of the 
way. 

(d) The Contractor shall install the WPCST and its peripherals to an Agency- 
provided portable cart. 

6.111- 11.9 Additional Security Requirements - CST 

11.9.1 Alarms 

(a) The CST shall be provided with an alarm that notifies the 
clearinghouse when an unauthorized entry occurs. 

(b) Both the alann and method of activation/deactivation shall be 
subject to Program Manager approval. 

11.9.2 Keys 

The Contractor shall provide to the Contract Administrator five (5) sets of 
all CST keys a minimum of 60 days prior to the delivery of the first CST. 

6.111- 11.10 Agency Specific Requirements 

11.10.1 (This section intentionally left blank. Section deleted per 
Change Order No. 5) 

11.10.2 Portable CST Application (Option) (NOTE - Section deleted per 
Change Order No. 49) Requirements included in CST section 

6.111-11 
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6.MI-12 Data Collection System 

6.111- 12.1 Subsystem Description - Data Collection System 

The data collection system (DR 109) shall consist of distributed data acquisition 
computers (DACs) throughout the region. DACs collect the data from On-Board, 
Portable and Stand-alone FTPs, GAKs or other designated RFCS equipment for 
transfer to the clearinghouse and provide the relevant Agency with duplicate data 
files of the data files transferred to the clearinghouse. 

6.111- 12.2 Functional Requirements - Data Collection System 

(a) The application program shall use an MS Windows standard graphical 
interface. 

(b) The use of proprietary hardware and/or software shall be subject to Contract 
Administrator review and approval. 

(c) The DAC shall operate without manual intervention. 

(d) All data up and down loading to the clearinghouse or to On-Board, Portable 
and Stand-alone FTPs shall be fully automated. 

(e) The DAC clock shall be synchronized with the clearinghouse clock prior to 
beginning a data transfer. 

(f) The Agency DAC shall allow access to a rolling 90 day database of complete 
trip transaction records for the Agency through the clearinghouse. 

(g) The DACS shall interface to the clearinghouse through the Back Office Client 
Computer per Section 6.III-13. 

6.111- 12.3 Performance Requirements - Data Collection System 

(a) The Contractor shall provide a detailed plan that describes the methodology of 
capturing and processing the data to be used to measure availability (DR 
109.01). 

(b) This plan is subject to Contract Administrator review and approval. 

(c) The Contractor may add equipment or increase system redundancy levels in 
order to meet or exceed availability requirements. 

(d) System availability shall be measured at a minimum for the following: 

i. DAC shall be available to transmit data to the clearinghouse 99.73% 
and to on- and off-load the data from the FTPs 99.73% during the 
scheduled time periods for these activities. 
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ii. The combined system elements such as FTP, WDOLs, DAC, and 

clearinghouse system shall be available 99.73% of the time when they 
are required for system operations. 

6.111-12.4 Physical Requirements - Data Collection System 

12.4.1 Data Acquisition Computer 

(a) The DACS shall consist of standard PC components with 
minimum requirements as follows: 


Component 

Requirements 

CPU 

Intel Pentium 4 or Xeon, operating at >1.5 
GHz. 1U or 2U rack configuration 



Network Interface Card 

10/100 Mb/s Ethernet NIC 



RAM 

>512 Mb 



Hard Drive 

>40Mb, 7200 RPM 

CD ROM 

>48x 

Removable Media 

CD R/W with software to write large data 
files across multiple CD’s 

Operating System 

Windows-based (NT, 2000, 2003, XP 
Professional) 


(b) The applications shall be programmed in high order languages 
such as JAVA, Visual Basic, or C++ and distributed objects. 

(c) Equipment will be installed in a secure location. 

(d) Each DAC shall have sufficient hard disk space to hold a minimum 
seven days of transactions. 

6.111- 12.5 Electrical Requirements - Data Collection System 

(a) The requirements specified in Section 6.III-1.5. shall be met. 

(b) In the event of a power interruption, a rechargeable dry or sealed gel cell 
battery source (or UPS) shall provide auxiliary power to the DAC for a 
minimum of 30 minutes of full operation; and shall allow for an orderly 
shutdown of the DAC, including completion of the transmission of all audit 
data and alann conditions to the clearinghouse. 

6.111- 12.6 Environmental Requirements - Data Collection System 

DAC shall be designed to operate in the environmental conditions provided in 

Figure III-12.1. 
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FIGURE 111-12.1 
OPERATING ENVIRONMENT 


Division III 



Data Acquisition Computers 


Temperature Range: 


Humidity: 


Shock: 


Other (dust, grit, rain/water 
protection): 


Climate controlled environment 


Climate controlled environment 


Minimum 20g non-operating, 2.5g operating. 


Applicable FCC requirements 


Climate controlled environment 


6.111-12.7 Data Exchange Requirements - Data Collection System 
12.7.1 RFC system Architecture 

(a) The Contractor shall develop a comprehensive RFC system 
Architecture, reflecting the interface requirements shown in 
Figure III-12.2. 

(b) The System Architecture shall include optional or alternative 
elements to be implemented in the future, as defined in this RFP or 
proposed by the Contractor. The Contractor may also propose 
additions to the core system architecture such as the provision of a 
headquarters computer. 

(c) The System Architecture shall be submitted with the design 
documentation and shall be approved by the Contract 
Administrator. 


12.7.2 Data Communications 


(a) The DACS shall communicate with the clearinghouse. 
Asynchronous communication using File Transfer Protocol (FTP) 
over TCP/IP at 56 kbps or greater shall be provided. 

(b) All batches shall be tagged with DACS header infonnation 
including as a minimum DACS ID, date stamp, and time stamp. 
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Figure IN-12.2 

REVALUE DEVICE AND COMPUTER SYSTEMS 
INTERFACE REQUIREMENTS 



B - Fare transactions 
C - Funds movement 
D - Revalue transaction data 
E - Fare transaction data 


G - Operational data 
FI - Reports/report data 
I - Fare control totals/data 
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(c) The DACS shall be equipped with required data communications 
interfaces including modem or network cards. 

(d) Under normal operations, all data transmission shall be initiated 
automatically. 

(e) Uploading of data from designated equipment to the DAC shall 
occur on a timed poll basis, at a minimum daily, or when 
equipment memory is at a predetermined threshold level. 

(f) Download of data to designated equipment from the DAC shall 
occur at Agency pre-determined times of-day. TheDAC shall have 
the capability to mirror the FTP displays in real time or allow the 
FTP transaction to be remotely monitored. 

(g) DACs installed at Sound Transit rail stations shall communicate 
through the existing TVM communications network. 

6.MI-12.8 Installation Requirements - Data Collection System 

(a) The Contractor shall install and setup all elements of the DAC in the designated 
Operating Bases and Agency offices. 

(b) Each Agency is responsible to provide a secure location for the equipment to 
prevent theft or damage. 

(c) The Contractor shall make all connections to power and communications, all 
connections between DAC elements, and route all cables neatly and out of the 
way. 

6.111-12.9 Additional Security Requirements - Data Collection System 

(a) Every access, authorized and unauthorized, to the DAC shall be logged and 
reported. 

(b) Data maintained by the DAC shall be protected from loss, manipulation, and/or 
disclosure through access control and cryptographic data integrity checking 
mechanisms. Any secret or private data shall be encrypted. 
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6.MI-13 Back Office Data Integration 

6.111-13.1 Subsystem Description 

Back office data integration shall include a client application (DR 110) to provide 
standard revenue and ridership reporting, RFC system reporting, Agency-specific 
reporting, ad-hoc query reporting, and fare table update functionality. The client 
application will provide the primary data interface to the clearinghouse system, and 
will contain functions for the generation of reports and transfer of data to legacy 
systems. The client application will also allow consolidated reports to be generated 
using fare card and non-fare card data transferred both from the clearinghouse system 
and directly from the data acquisition system (non-fare card data recorded by the 
FTPs). 

The client application shall be designed to operate on a standard PC-based 
workstation at each Agency (either provided by the Agency or provided under this 
Contract). Communications to the clearinghouse system shall be via LAN/WAN or 
other means (e.g. asynchronous dial-up). The Agencies are interested in solutions 
that leverage off modern client-server or N-tiered application development 
technology. 

The Client Application (in conjunction with local server if applicable) shall support 
the following high level business functions: 

1. Revenue Information and Reconciliation - This is the information typically 
needed daily for posting to the Agencies General Ledger application. Some 
Agencies require categorized totals for manual entry to the GL (e.g. 8-10 data 
points representing sales by pass type, and realized e-purse revenue by fare type). 
Other agencies require transaction level revenue data. 

2. Ridership Information and Processing - This is information on fare card use, 
provided at the transaction level, or summarized daily, weekly, monthly, quarterly 
or other period, used by each Agency to report ridership characteristics for local 
and regional reporting. 

3. System Performance Reporting - This is information about the performance of 
the RFC system including management information reports such as financial 
management, customer service, inventory systems operation, and system 
status/maintenance reports such as fault tracking, exceptions, and support service 
statistics. 

The client application shall include a data export functionality to export/transfer data 
from the clearinghouse system and DACS to each Agency’s legacy revenue and/or 
ridership systems. This functionality could be implemented via industry standard 
software techniques such as batch-automation, real-time connectivity, or manual data 
entry, depending upon the system integration requirements of each participating 
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Agency. This will allow the Agencies to generate custom reports with their existing 
back-office systems. 

Flexibility and extensibility is also required to allow the creation of new reports, 
modify existing reports, and administer new types of fare tables to support new fare 
policies such as distance based fares. 

6.111-13.2 Functional Requirements 

13.2.1 Back-Office Client Application 

(a) The client application for the back-office system integration is 
designed to be the common data-management solution for all 
participating Agencies. The client application functional 
requirements shall complement the Agency specific integration 
functional requirements. 

(b) The Contractor shall be responsible for providing workstation 
hardware and software for the client application at each Agency. 

(c) The back-office client application shall include capabilities for an 
agency to correct erroneous data or reports, and update 
clearinghouse and other databases and reports automatically. This 
does not include changing revenue data. 

13.2.1.1 Clearinghouse Data Reporting 

The Contractor shall develop reports as specified in 6.III-13.3, Data 
Exchange and Reporting Requirements. All reports shall be generated by 
the back-office client application. 

13.2.1.2 Agency Specific Fare Table Administration (DR 110.01) 

(a) The back-office client application shall administer and 

electronically transfer fare table data to the clearinghouse. The 
following list of properties is provided as a guideline for the 
Agency’s fare table input, and subsequent transfer to the 
clearinghouse: 

i. Agency I.D. 

ii. Unique Fare ID Reference 

iii. Description String of Fare Type 

iv. Start Date/End Date 

v. Fare Amounts 

vi. Rider Demographic Category fare rules 

vii. Rider Peak/Off-Peak fare rules 
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viii. Rider Frequency-based fare rules 

ix. Rider Day-of-Week fare rules 

x. Rider Holiday fare rules 

xi. Inter-Agency Rider commute fare rules 

(b) The back-office client application shall administer existing fare 
tables, and shall be extensible to administer new local and inter¬ 
system fare tables. 

(c) The back-office client application shall administer a minimum of 
three (3) fare tables: Prior, current and those for the next fare or 
service change. 

(d) The client application shall have read-only access to the fare table 
from the preceding service period. 

(e) The client application shall include functionality to test fare tables 
prior to forwarding to the clearinghouse. 

13.2.1.3 Agency User Administration 

The back-office client application shall provide the following user 
administration functions: 

(a) Add new Agency user 

(b) Update Agency user 

(c) Remove Agency user 

(d) Disable Agency user 

13.2.1.4 Agency Application User-Defined Environment Views 

The back-office client application shall provide the following user defined 
environment views: 

(a) Standard User View - Whereby the user will be only able to view a 
standard Agency operational view of data and application 
features. 

(b) Standard Power User View - Whereby the user will be able to view 
a standard Agency managerial view of data and application 
features. 

(c) Standard Administrator View - Whereby the user will be able to 
view a standard Agency RFCS back-office integration 
administrative view of data and application features. 
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(d) Customized View - Whereby the user can configure the application 
to show only user-relevant information in which they are permitted 
to interact with based on their security clearance level. 

13.2.1.5 Import/Export Report Data 

The back-office client application shall provide the following data 

import/export functions. All functions shall be available for all report 

categories specified in 13.3: 

(a) Data Files (Import Source / Export Destination) - This option will 
include the ability to specify input or output file fonnat including, 
but not limited to Comma Delimited, User Defined Delimiters, 
Fixed Field Width, and XML (a tagged data fonnat). 

Note: The XML export option will support the direct republishing 
of summary information on an Agency Intranet, or the Internet (in 
the case of infonnation open to the public). Specifications and 
additional information on XML can be obtained from 
http://www.w3.org/xml. 

(b) DSN Resource (Import Source / Export Destination) - This option 
will facilitate the transfer of data from the clearinghouse to 
Agency’s local systems. In this function the user shall be able to 
specify a target Data Source Name (DSN) and table. The system 
shall accept a user-defined compatible DSN (column count, and 
data types) for the destination table. The interfaces for this 
function shall accept user input of any DSN entries configured on 
the workstation via the Windows control panel, or equivalent 
workstation interface. 

(c) Printing (Export Destination) - The user will be able to select from 
a list of printers configured for the client application’s operating 
system. Connection to the printer may either be direct (serial or 
parallel) or via a local area network (LAN). The client application 
should take advantage of Operating System print servers to 
maximize the number of printers compatible with the application. 

13.2.1.6 RFCS Database Connectivity 

(a) The Contractor shall provide connectivity to the clearinghouse 
database that meets all the requirements for access and 
performance described in this document. 

(b) The Contractor shall provide a connection strategy that is 
consistent with modem wide-area computing technology. 
Whenever possible the Contractor shall utilize industry standard 
technology (connectivity hardware, communications protocols, 
replication technology, etc.). 
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(c) The Contractor shall provide failure analysis documentation for the 
proposed connectivity strategy. This document will address 
emergency recovery plan, and emergency (or "off-line") operation 
procedures. 

(d) The system shall notify the Agency system administrator of 
communications failures to the clearinghouse system. 

(e) The client application shall not remove, delete or alter data records 
at the clearinghouse system. 

13.2.1.7 RFCS Database Archive Administration 

This feature allows archiving of data transferred to the client application; 
it does not include archiving or modification of data at the clearinghouse 
system. 

(a) The Contractor shall provide an archive function to provide the 
Agency with off-line or near-line storage of historical 
information. The back-office client application shall provide the 
following database archive functions: 

i. Agency-specific archive. The system shall allow data to be 
archived weekly, monthly, and quarterly (3 months) to the 
target media. The archive scheduling shall be 
programmable by each Agency. 

ii. Inter-Agency Archive Subset. This will archive Inter- 
Agency information to the target media. The Agency may 
wish to keep Agency-specific historical infonnation on-line 
longer than Inter-Agency information. 

(b) Records in an archive set shall be flagged or stamped with the 
current date and time. Incremental archiving shall be provided. 

(c) Each Agency will be responsible for implementing the 
administrative duties of the archival process. The archive function 
shall support industry standard media (tapes, disks, CD's) typical 
for the workstation architecture and operating system. 

13.2.1.8 Inter-Agency Data Sharing Filter Administration 

The back-office client application shall provide the following inter- 
Agency data sharing filter administration functions. These are features of 
convenience, designed to allow the user to display or hide data in a 
specific view. 

(a) {Display | Hide} All Agency Public records 

(b) {Display | Hide {Specified Agency Public records 
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(c) {Display | Hide } Specified Agency Private records 

(d) {Display | Hide } Specified Inter-Agency records 

13.2.1.9 Event Logging 

The back-office client application shall provide the following event 
logging functions. The log entries shall occur automatically, and without 
user intervention: 

(a) Agency Fare Table Administration Events 

(b) Pass Sales Transactions 

(c) Agency User Administration Events 

(d) Batch Scheduled/User Executed Report Generations Events 

(e) Performance metrics for report generation/data sharing events 

(f) Data Import/Export Events 

(g) Database Query Errors 

(h) User Security Events 

(i) Inter-Agency Data Sharing Administration 

(]) Inter-Agency Data Sharing Transactional Events 

(k) Clearinghouse data transactions 

13.2.1.10 Local Fare Card Revenue Control Total Reporting 

The definition of the control total reporting method is a one to one 
aggregate comparison between totals from the DACS set of revenue detail 
records and the totals from the clearinghouse set of revenue detail records 
for a particular Agency business day. The difference between DACS 
revenue total and the clearinghouse revenue total is defined as the control 
total variance. Control totals provide an approximation of fare collection 
revenues owed to an Agency, but are not expected to represent true 
revenue owed once all transactions have been reconciled. 

(a) The back office client application shall include functionality to 
process and report total reconciled and un-reconciled fare card 
revenue collected at each Agency. 

(b) Reports shall be provided on a daily basis. 
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(c) The back office client application shall compare control totals 
received from the DACS with reconciled totals received from the 
clearinghouse on a daily basis. 

(d) The back office client application shall create a variance report and 
report the source of the variance. 

(e) The back office client application shall activate an alarm if a 
control total variance exceeds a user-defined threshold. 

13.2.1.11 Consolidated Fare Card and Non-Fare Card Ridership Reporting 

(a) Some Agencies will collect non-fare card data through the fare 
transaction processors. The back-office client application shall 
include functionality to process and generate consolidated 
ridership reports for all fare card and non-fare card data recorded 
on the fare transaction processors. 

(b) The back office client application shall include functionality to 
correct “double counting” of fares that include a fare card 
underpayment, coupled with a non-fare card “upgrade”. 

13.2.1.12 Ad-Hoc Reporting 

The back-office client application shall include the following ad-hoc 

reporting functions. 

(a) A graphical interface for the creation of the database query. The 
user can choose table(s), field(s), conjunctions, conditionals, and 
output order (ascending or descending). The user can select one or 
two field(s) for "Group-by" to organize the results in a hierarchy 
(e.g. report on annual pass sales per month group-by 'sales- 
location’). 

(b) A query editor that allows the user to create a new query using a 
standard structured language. This same interface may be used to 
edit a query that was built from the graphical query builder. 

(c) A graphical interface for the creation of the report formats. The 
user will be able to define page size, margins, footers, headers, 
page breaks, font size and style, and simple graphical elements. 

(d) A function to save a report design for future execution, or editing. 

(e) A query batch submission service feature, which would enable the 
Agencies to have query/report results, sent to the submitting 
Agency via standardized digital media (e.g. DAT tapes). This 
service would reduce network bandwidth usage and improve data 
accessibility. 
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13.2.1.13 Business Day 

(a) The Contractor shall coordinate the upload and download of data 
based on each Agency’s administrative business day. 

(b) The Contractor shall be able to handle changes to the Agency’s 
administrative business day. This may require coordination with an 
event triggered by the Agency (as opposed to a time table system). 

13.2.2 Functional Requirements (Agency Specific) 

The Contractor shall develop the Agency client application to meet the 
following requirements: 

(a) Provide reports/data for integration into existing Agency reports 
and databases. 

(b) The client application shall be integrated with the following legacy 
systems: 

i. King County Metro, ASCII data file or direct ODBC 
connection to a workstation to be provided by KCM. 

ii. Washington State Ferries, integration with new revenue 
collection system as described in 6.III-16.7. 

iii. Kitsap Transit, ASCII data file transfer. 

iv. Pierce Transit, Oracle DBMS and Microsoft SQL 
RDBMS. 

v. Community Transit, Oracle DBMS. 

vi. Everett Transit, no legacy system. 

vii. Sound Transit, Central Data Collection System (CDCS - 
under development). 

(c) The Contractor shall coordinate with Agency personnel and other 
contractors supporting legacy systems as listed in Figure III-13.1. 

(d) The Contractor shall be responsible for developing the client 
application such that it is compatible and integrated with existing 
systems. 
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Figure MI-13.1 

LEGACY SYSTEM SUPPORT CONTRACTORS/PERSONNEL 


Agency 

Contractor 

King County Metro 

KCM staff 

Kitsap Transit 

KT staff 

Pierce Transit 

PT staff 

Community Transit 

CT staff 

Everett Transit 

Solutions for Government (SFG) and 
City staff 

Sound Transit 

To be determined at implementation 

Washington State Ferries 

WSF staff 


13.2.2.1 King County Metro (DR 110.02) 

(a) Daily sales reports shall be provided to the Finance Department for 
automated and/or manual entry to the general ledger or accounts 
receivable system(s). Sales information shall be broken down by 
pass type and by vendor identifier (e.g. Consignment, Group Sales, 
RFCS managed sales). Transaction revenue (from stored value) 
shall be broken down by Peak, Off-Peak, and Special fares (Senior, 
etc.). Files for automated entry shall be provided using ASCII file 
export or ODBC connection. 

(b) Transaction level Ridership data (including driver and vehicle 
assignment information, and all trip data) shall be provided 
through electronic data transfer to the KCM server. This 
requirement could be met by the Import/Export Report 
requirements using either ASCII file export as an intermediate 
step, or direct ODBC transfer if the KCM Transit Distribution 
Database supports this. 

(c) Currently, KCM’s administrative business day is defined as 8 a.m. 
to 5 pan. KCM maintains a separate “service day” for transit 
operations. 

13.2.2.2 Kitsap Transit (DR 110.03) 

(a) Daily revenue reports from the RFC system shall be provided by 
fare type. These will be manually entered into the existing 
Fundware general ledger system. 

(b) On a daily basis, ridership data from the client application shall 
generate a formatted ASCII data file via the client application data 
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export feature. This data file/ODBC connection data shall be 
imported into an existing Microsoft Excel system. 

(c) At the time this specification was written, a final decision about a 
new accounting system had not been made. The most likely 
product under consideration is “Fundware for NT”. The Contractor 
shall provide functionality to export data to this product 

(d) Currently, KT’s administrative business day is defined as 8 a.m. to 
5 p.m. 

13.2.2.3 Pierce Transit (DR 110.04) 

(a) RFCS revenue data shall be transferred to the existing finance 
system via ODBC type middle-ware, or by transfer command in 
the back office client application. 

(b) Pierce Transit operates a financial system using an Oracle 
RDBMS. 

(c) Currently, PT’s administrative business day is defined as 8 a.m. to 
5 p.m. 

13.2.2.4 Community Transit (DR 110.05) 

(a) Community transit is implementing a new ERP system based on 
Oracle financial packages, using Oracle 7.3.n or Oracle 8 as the 
back-end. The client application shall interface with this system 
via ASCII data file transfer in CSV fonnat or direct ODBC 
connection to a workstation provided by CT. 

(a) The Contractor shall provide daily revenue reports broken down 
by fare and pass types. These numbers will be manually entered 
into the GL system. 

(b) Community Transit has contracts with third-party transit providers, 
who are responsible for their own revenue reporting. The back- 
office client application shall report all third party fare card 
revenue, summarized by provider. 

(c) Currently, CT’s business day is defined as 8 a.m. to 5 p.m. 
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13.2.2.5 Everett Transit (DR110.06) 

(a) Daily reports from the RFC system shall be provided summarizing 
sales by fare type. These will be manually entered into the existing 
financial systems. Currently, Everett Transit hosts a legacy 
COBAL financial system called SFG. They also use Microsoft 
Excel to aggregate revenue and ridership data. Everett Transit has 
no current plans to upgrade their existing systems. 

(b) Currently, ET’s administrative business day is defined as 8 a.m. to 
5 p.m. 

13.2.2.6 Sound Transit (DR 110.07) 

Sound Transit (ST) is implementing an Automated Fare Collection system 
that will eventually become integrated with the RFCS. ST’s system will 
collect fare data from ticket vending machines and validators, and transfer 
that data to the Central Data Control System (CDCS). The CDCS will 
provide the ST interface with the client application and clearinghouse 
system. 

Sound Transit will also be installing fare collection (farebox and RFCS 
fare card) equipment on new bus services. 

(a) The RFCS Contractor shall coordinate with the ST Contractor to 
provide the necessary infonnation to integrate the ST system into 
the RFCS. The ST Contractor will be responsible for making any 
necessary modifications to the CDCS to accommodate the upload 
of information from CDCS to the RFCS clearinghouse. 

i. The RFCS Contractor shall provide ST with the application 
software to transfer RFCS transaction data from the CDCS 
to the clearinghouse system. 

ii. The RFCS Contractor shall provide ST with the software 
drivers and RFCS card application for the TVM card 
readers. 

(b) The RFCS Contractor shall provide to ST the transaction data 
format required to complete modifications to CDCS for transaction 
uploads to the clearinghouse. Refer to Appendix B-5 for a 
preliminary list of messages. These messages are subject to change 
as Sound Transit implements its Ticket Vending Machine project. 

(c) Currently, ST’s administrative business day is defined between 8 
a.m. - 5 p.m.. 
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13.2.2.7 Washington State Ferries 

Washington State Ferries is implementing a Revenue Collection system 

(RCS) that will be integrated with the RFCS as described in Section 6.HI- 

16. The RCS will collect smart card fare data through the RFCS, and will 

provide the interface to RFCS subsystems and the clearinghouse. 

(a) The Contractor shall coordinate with WSF and the RCS contractor 
to provide the necessary information to integrate RFCS systems 
with the RCS. 

(b) The Contractor shall provide WSF with the application software to 
transfer RFCS transaction data from the RCS to the clearinghouse. 

(c) Currently WSF’s administrative business day is defined as 8:00 
a.m. to 5:00 p.m. WSF maintains a service day from 4:00 a.m. to 
3:00 a.m. the following calendar day. 

13.2.3 RFCS Client Application Support 

(a) The Contractor shall provide on-site technical services necessary 
to fulfill the functional requirements of each Agency’s back-office 
functions connected with the RFC system. 

(b) The Contractor shall provide scheduled and emergency on-site 
maintenance of the client application. 

6.111-13.3 Data Exchange and Reporting Requirements 

(a) The RFCS shall provide the following minimum data exchange and reporting 
between the clearinghouse and each Agency’s existing revenue and ridership 
systems: 

i. Standard System Perfonnance 

ii. Standard Ridership and Revenue 

iii. Ad-hoc Ridership and Revenue 

(b) All reports shall be generated using a query language and standard query 
engine (to be approved by the Contract Administrator) that provides flexibility 
for future updates, and for creation of new reports. 

(c) Report writer software shall include the ability to generate graphs and charts 
based on criteria and fonnat defined by the user. 

(d) Where applicable, shall be designed to generate with variable data and time 
parameters allowing dynamic user selectable criteria such as start/end dates 
and data content. Report generation may be restricted by processing rules 
when necessary to minimize impacts on system processing resources (such as 
preventing full database passes). 
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13.3.1 


Standard System Performance Reporting 

Where applicable, the RFCS shall generate the following standard system 
reports automatically on an agreed schedule defined for each report. 

When required, and respective of system processing rules, the report(s) 
may also be run on demand. Report generation may be restricted by 
processing rules when necessary to minimize impacts on system 
processing resources (such as preventing full database passes) 

(a) Financial management reports, including as a minimum: 

i. Daily Sales by Participant 

ii. Daily Sales by Payment Type 

iii. Exception Items 

iv. Missing Add Value Transactions 

v. Net Settlement Position for all program participants 

vi. Daily Settlement Position reports including: 

(2) Settlement account and bank account identifiers 

(3) Purse transactions summarized by sales, fare 
payments, transfer adjustments, refunds, and 
escheatment value transfers 

(4) Sales transactions summarized by purse sales, sales 
of own products, sales of other Participants 
products 

(5) Other transactions summarized, including but not 
limited to (based on Participant), manual 
adjustments, apportionment values, expired 
transaction value, transfers from Institutional or 
Lead Agency accounts 

vii. Transaction summary information based on the 
Clearinghouse settlement date for Agency, centralized role, 
or retailer 

viii. Transaction summary information showing when 
transactions were processed through settlement, by the 
Agency’s reconciliation date 

ix. Claim transactions for all system participants 

x. Manual adjustments 

xi. Total liability owned by the Agencies for Purse Values 

xii. Provide details of all inactive cards to support both internal 
and Washington State escheatment processes 
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xiii. Automatic revalue transaction information, including 
product type, volume and value, reflecting the date the fare 
card was updated with the value 

xiv. Revenue from sales of regional passes apportioned across 
Agencies. Data will be subject to appropriate system 
business rules that govern calculation and allocation of 
regional pass revenue 

xv. Revenue from Purse Transfers distributed and adjusted for 
all Agencies. Data will be subject to appropriate system 
business rules that govern calculation and allocation/re¬ 
allocation of purse transfer revenue 

xvi. Revenue from sales of regional passes within Institutional 
programs apportioned across Agencies participating in the 
program. Data will be subject to appropriate system 
business rules that govern calculation and allocation of 
regional pass revenue 

xvii. Instances of NSF transactions results from a bad check or 
post payment automatic revalue 

xviii. Successfully processed card refunds 

xix. Statistics about the sales made at a 3 rd Party Retailer and 
their associated locations 

(b) General management information reports, including as a 
minimum: 

i. System utilization reports 

ii. Fare card reliability statistics, measuring the rate of failures 

iii. Device reliability for all device types in the program. This 
should exclude failures such as power outages, accidents or 
mishandlings 

iv. Device status and availability, including historical data 

(c) Contractor provided customer service reports, including as a 
minimum: 

i. Call center level of service and perfonnance against quality 
standards 

(d) Website performance data including statistics on the use and 
uptake of all areas of the RFCS website pages 

i. Summary of activity by hour, day, and month 

ii. Ridership by web page, including total number of hits, hits 
by entry pages, and hits by exit pages 
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(e) Institutional program reports, provided to both the Agencies and 

institutions, including as a minimum: 

i. Institutional program participation based on RFCS fare 
media usage on a RFCS card. 

ii. Institutional program ridership statistic summaries showing 
the cash equivalent value and the value actually received 
by the Agency providing the transit service. 

iii. Institutional program ridership statistics by Agency 
providing the transit service, the route, and other fare 
payment transaction detail. 

iv. For Agencies and Commercial Accounts only, provide 
transaction history for Institutional cards (monthly or for 
specified date range). 

v. Billing data including summaries of redeemed/unredeemed 
vouchers and customized programs. 

vi. Institutional program data to show the number of cards 
issued in an Institutional program, the products on the cards 
and whether the products and card being actively used or 
not. 

vii. Details of products that an Institution has ordered, but were 
never redeemed during the billing or agreement period. 

viii. Details of vouchers that an Institution has ordered, but were 
never redeemed during a specific period. 

ix. Vanpool use by Institution, Vanpool ID, Agency, and/or 
card serial number, accessible by the vanpool administrator 
at each Agency. 

x. Details of vanpool subsidies used on vanpool services, 
accessible by the vanpool administrator at each agency. 

xi. Business Account transaction history report which excludes 
the card serial number and passenger type fields. 

(f) Card management reports, including as a minimum: 

i. Detailed list of all smart cards by RFCS location, type and 
card status, throughout the asset management lifecycle 

ii. Details of all Agency orders in the RFCS 

iii. Delivery performance 

iv. Bad stock, returns, and defects 

(g) System maintenance reports (DR 110.09), including as a 

minimum: 

i. System-wide inventory report 
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ii. Device faults and support services statistics 

iii. Device warranty periods (including current and extended 
periods) 

iv. Status of all device support reports managed by the 
Contractor repair center, by Agency (location and owner), 
and device type 

v. Details of devices (non-spare) that did not connect ot a 
DAC during the reporting period 

vi. Provide audit data to assist in confirmation that transactions 
are sent from devices, received, and processed by the 
Clearinghouse. 

13.3.2 Standard Fare Card Ridership and Revenue Reporting 

13.3.2.1 National Transit Database Reporting (DR 110.10) 

(a) The RFCS shall generate data extracts of unlinked passenger trips 
for each Agency to use to prepare their NTD reports. The extracts 
shall include: 

i. Annual unlinked passenger trip totals. 

ii. Average weekday, Saturday and Sunday unlinked 
passenger trip totals. 

iii. Unlinked passenger trips by mode including motor bus, 
trolley bus, vanpool, rail, and demand responsive services. 

(b) The RFCS shall generate data extracts with passenger fare 
information for each Agency to use to prepare their NTD reports. 
The extracts shall include: 

i. Total passenger fares. 

ii. Fares by fare category, including as a minimum full-fare 

(adult), senior citizen, student, special fares. 

iii. Fares by mode, including as a minimum motor bus, trolley 
bus, vanpool, rail, and demand responsive services. 

13.3.2.2 Common Ridership and Revenue Reporting (DR 110.11) 

The RFCS shall generate the following ridership and revenue reports for 

each Agency. 

(a) Ridership reports containing information as listed below. The 

reports will run daily, monthly, and by user-specified date range: 

i. Route. 

ii. Agency or contractor owning coach. 
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iii. Service or agency operated under. 

iv. Transit Operator (where applicable) 

v. Fare category (per the fare categories of each respective 
Agency), and exceptions or upgrades. 

vi. Fare payment type and value of payment. 

vii. Average weekday ridership (monthly report). 

viii. Average Saturday ridership (monthly report). 

ix. Average Sunday ridership (monthly report). 

x. Unlinked trips boardings). 

xi. Intrasystem transfers for a standard reporting period (e.g. 
Monthly) and available on-demand for a user-selected 
period. The report should also be available on-demand at 
the Route level if specified. 

xii. Intrasystem transfers for a standard reporting period (e.g. 
Monthly) and available on-demand for a user-selected 
period. The report should also be available on-demand at 
the Route level if specified. 

(b) Monthly status of the number of fare card issued in the reporting 
period. Provide a breakdown of the revenue earned by Agency 
by: 

i. The value of the products added to those cards by product 
type in the reporting period. 

ii. The number of fare cards used in the period and the 
revenue earned by Agency, by product. 

(c) Pass/Multi-Ride sale/revalue summaries, broken down by: 

i. Sales/revalue location identification. 

ii. Product (type and face value). 

iii. Revalue amount. 

iv. Subsidy amount and type. 

(d) Fare underpayment report to identify those transactions in which 
additional cash fare was required (not whether it was paid), 
including the following information: 

i. Card serial number. 

ii. Product (type and face value). 

iii. Route identification. 

iv. .Expected amount. 
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v. Amount of underpayment. 

vi. Route owner or transit operator. 

(e) Counts from regional counters for non fare card usage 

13.3.3 Ad-Hoc Fare Card Ridership and Revenue Reporting 

Through the back office client application, the RFCS shall provide each 
Agency with the ability to prepare ad-hoc reports (DR 110.12) using 
business views created either directly against data generated by RFCS 
devices or derived from data supplied by the Agencies and imported in the 
RFCS. The reporting ability should include at a minimum: 

(a) Transaction-level reports for user-defined start and end dates, 
including at a minimum the following fields or subset thereof 
defined by the user. The data available will be constrained 
according to the relevant system business rules regarding 
transaction validity, availability, and governing revenue 
determination and allocation: 

i. Card Number or Identifier 

ii. Institutional ID 

iii. Vehicle ID 

iv. Route ID 

v. Run ID (bus and rail) 

vi. Trip ID (bus and rail) 

vii. Device ID 

viii. Vehicle owner, route owner, or transit operator 

ix. Date of transaction 

x. Time of transaction 

xi. Amount or value of transaction and product type 

xii. Valid fare payment, upgrade or underpayment 

xiii. Linked or unlinked trip 

xiv. Agency transferring from (if applicable) 

xv. Route or terminal transferring from (if applicable) 

xvi. Run transferring from (if applicable) 

(b) Statistical and research reports using user-defined criteria. 
Examples include: 

i. Usage characteristics for user-defined customer market 

segments, potentially broken down by type of fare payment 
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used (cash, purse, pass, multi-ride etc.), route, period of 
travel, and/or frequency of travel. 

ii. Product type used versus cash equivalent full fare value. 

iii. Card revalues by revalue location. 

(c) Functionality for generating reports on a regional basis, including 
linked trips, unlinked trips, and transfers for any combination of 
Agencies in the region. Provisions shall be included to limit user 
access to Agency-specific data per permissions and policies of 
each individual Agency. 

(d) Financial management reports using user-defined criteria. 
Examples include: 

i. Card account activity 

ii. Financial trend analysis 

(e) Fraud management reports using user-defined criteria. Examples 
include: 

i. Transactions by specific card(s) 

ii. Transactions on lost, stolen, damaged, or replaced cards 

iii. Transactions occurring at any location outside of specified 
business hours 

iv. Transactions by device or CST operator 

(f) Boardings and revenue associated with ridership transfers, purse 
transfer and linked trips between Sound Transit and local Agencies 
(Community Transit, Everett Transit, King County Metro, and 
Pierce Transit) on a daily, weekly, monthly, and year-to-date basis. 
The information provided will be constrained by system business 
rules governing revenue calculation and allocations. 

i. Total value of purse transfers and linked trips between 
Sound Transit and each local agency classified by each 
type of product, full payment by purse, and payment by 
product and purse indicating product classification used 
and amount of purse upgrade. 

ii. Allocation and disbursement of actual revenue collection 
between Sound Transit and each local agency. 

(g) Boarding and revenue associated with linked trips and purse 
transfers between local agencies (Community Transit, Everett 
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Transit, King County Metro, and Pierce Transit), based on the 
system business rules governing revenue calculation and 
allocation. 

i. Total value of linked trip and purse transfers between local 
agencies classified by each type of product, full payment by purse, 
and payment by product and purse indicating product classification 
used and amount of purse upgrade. 

ii. Allocation and disbursement of actual revenue collected 
between local agencies. 

13.3.3.1 Agency Specific Fare Card Ridership and Revenue Reporting 

In addition to the standard and ad-hoc reports, the Contractor shall provide 
data extracts of transaction summary data from the BOC and transaction 
data from the Clearinghouse to support the ability for Agencies to create 
Agency specific reports on an ad hoc basis. (DR 110.13). Sample report 
formats are contained in Appendix B. Except where noted, the Contractor 
may provide alternative report formats, subject to approval by the affected 
Agencies. 

The ad hoc reports will be created either directly against data generated by 
RFCS devices or derived from data supplied by the Agencies and 
imported into the RFCS. The data may be available at the Clearinghouse 
or at the Back Office Computer. 

(a) King County Metro 

The Contractor shall provide the ability to create ad hoc reports to support 
the following KCM needs (samples of King County reports are provided 
in Appendix B-2). 

i. Purse, pass, multiride revenue associated with passenger 
trips 

ii. Number of passes in use 

iii. Monthly and year-to-date totals for all fare card product 
transactions by fare category type 

iv. Monthly passenger trip counts for all product transactions 
broken down by day of month and day of week, showing 
the total number of riders per day for each category of 
transaction 

v. Daily total for all fare card product transactions to illustrate 
the outstanding fare media in use and sold for the month 

(b) Kitsap Transit 
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The Contractor shall provide the ability to create ad hoc reports to support 
the following Kitsap Transit needs (sample of Kitsap Transit reports are 
provided in Appendix B-3): 

i. Driver shift report listing rider head count over the span of the 
shift. 

ii. Ridership counts broken down by weekdays, Saturdays, or 
Sundays. 

iii. Number of riders by route location and total passengers for the 
location for the specified timeframe. 

(c) Pierce Transit 

The Contractor shall provide the ability to create ad hoc reports to support 
the following Pierce Transit needs (samples of Pierce Transit reports are 
provided in Appendix B-4): 

i. Revenue and ridership reporting compatible with the Average 
Daily Ridership report described in Appendix B-4. The first two (2) pages 
of E-4 contain a sample report that shows how Pierce Transit breaks up 
bus fleets and route categories. This is provided for illustrative purposes, 
but does not include the full range of fields that will be required for RFC S 
implementation. 

ii. Wheelchair lift utilization by fleet type (boardings only) 

iii. Bicycle boardings by route and fleet type 

iv. Average and Peak Report 

Peak ridership is the average (over multiple days) of the maximum 
number of passenger boardings in a specified time period. 

(1) Average Weekday Ridership 

(2) Average Saturday Riderhip 

(3) Average Sunday Ridership 

(4) Seattle Express Northbound Peak 

(5) Seattle Express Southbound Peak 

Examples of these charts have been provided in Appendix B-4. 


vi. Average and total passenger boardings by trip number and 
route. This may be included as part of the Common 
Ridership and Revenue Reports described in 13.3.2.2. 

vii. Monthly reporting by revenue categories, totals by product, 
and totals by fare type. The data available will be governed 
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by the system business rules regarding revenue allocation 
and distribution. The RFCS may cause some product types 
to be obsolete, and may add new types to the report. An 
example is contained I Appendix B-4. 

viii. Daily sales counts of products by sales outlet. The example 
report is an excellent resource for product types that the 
system shall support for integration with Pierce Transit. 
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(d) Community Transit 

The Contractor shall provide the ability to create ad hoc reports to the 
following Community Transit needs (samples of Community Transit 
reports are provided in Appendix B-l): 

i. Number of passenger boardings by route and performance center 
for weekdays, Saturdays, and Sundays. 

ii. Payment type (cash, purse, period pass, transfer, etc.) and amount. 
By route and performance center for weekdays, Saturdays, and 
Sundays. 

iii. Product type by route and performance center for weekdays, 
Saturdays, and Sundays. 

iv. Fare category (senior, youth, disabled) by route and perfonnance 
center for weekdays, Saturdays, and Sundays. 

v. Number of transfers to/from other RFCS transit systems and the 
associated routes. 

vi. Number of intrasystem transfers at the route and performance 
center level. 

vii. Provider reports: 

This category is required for CT to support their existing business 
practice of multiple service contracts. The Contractor shall 
provide the ability to generate ad hoc reports for quarterly 
ridership and revenue summary reports for each contracted transit 
operator. The availability of revenue data is governed by the 
system business rules used to calculate and allocate revenue. 

(1) Sales by retail location, including the total of each category 
of item sold 

(2) Sales by performance center 

(3) Sales by retailer 

(4) Summary of cash receipts by category that reconciles with 
the daily total cash receipts 

(e) Everett Transit 

i. The Contractor shall provide ad hoc reporting capability for the 
preparation of Everett Transit reports. 
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(f) Sound Transit 

The Contractor shall provide data exchange for the preparation of reports 
by Sound Transit’s CDCS per the data requirements contained in 
Appendix B-5. Additional data exchange and financial reporting 
requirements for Sound Transit, beyond the standard reports, is currently 
under review. 

(g) Washington State Ferries 

The Contractor shall provide ad hoc reporting capability for the 
preparation of WSF reports with content as listed under 6.Ill-13.3.4.1 
(King County Metro). 

13.3.5 Non-Fare Card Transaction Reporting (DR 110.14) 

(a) At the direction of each Agency, the reports listed in Sections 
13.3.2, 13.3.3 and 13.3.4 shall include and consolidate non-fare 
card data collected through the fare transaction processor and data 
acquisition system. 

(b) Non-fare card data shall be listed as one or more additional fare 
types. As a minimum, a “cash” fare type shall be included. 

6.111-13.4 General Computing Environment 

The intent of this section is to illustrate general industry guidelines and Agency 
preferences for hardware and operating system software. It is also the intent of this 
section to include, and not limit this application to, a multitude of application 
technology solution types for the Agency Back-office Integration. 

(a) The Contractor shall provide a back-office solution that is compatible with the 
computing environment of each Agency. 

(b) The Contractor shall provide the exact specifications for new systems to be 
integrated with legacy systems to the Agencies and their designates, including 
other Contractors responsible for legacy systems. 

(c) The Contractor shall provide a means for users to manage processes or sub¬ 
processes (threads) of the client application. This requirement may be fulfilled by 
using native operating system utilities to monitor, pause, or terminate lengthy 
processes as needed. 
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13.4.1 Back-Office Client Application Computer 

(a) The Back Office Client Application Computer shall meet 
minimum standards as listed in Section 6.III-12.4.1, and shall be 
approved by the Contract Administrator (DR 110.15): 

(b) Data back-up and redundancy shall be provided to protect against 
data loss. 

6.111-13.5 Performance Requirements 

13.5.1 Back-Office Client Computer 

(a) Upon database query, print, or any other application function, the 
application shall return control to the user within five (5) seconds 
of initiation. 

(b) All transactions shall be successfully processed. 

13.5.2 Data Transfer and Report Generation Response Time 

(a) Fare Table Updates: Fare table transfer to the clearinghouse 
system shall be completed in less than ten (10) seconds. 

(b) Standard Reports: Existing instances of standard reports shall be 
generated in less than ten (10) seconds (this does not include the 
printer time to complete the output). On-demand generation of 
standard reports will vary based on the complexity of the data set 
and selected parameters. 

"Complete" is defined as - "Full control of the workstation has returned to 

the user". Background processing strategies may be implemented to fulfill 

response time requirements. 

13.5.3 Reliability and Accuracy 

(a) Reporting process: All reports shall perform the correct 
calculations for sub-totals, totals, and summary information (all 
derived information) with 100% accuracy. The underlying 
standard report design (including mathematical formulas) shall be 
available to the Agencies for review. 

(b) Fare table updates: The Back-Office Client shall correctly transfer 
the Fare Table revisions to the clearinghouse system with 100% 
accuracy. 

(c) Transaction recording functions: The Back-Office Client shall 
correctly store infonnation into the clearinghouse database with 
the appropriate field and form level validation. 
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6.MM3.6 Installation Requirements 

(a) The client application and all of its supporting hardware and software shall be 
installed by the Contractor. At each Agency's discretion, Agency personnel 
may perform the installation. 

(b) The Contractor shall design and develop a simple to use installation program 
for the client application software. This program should be designed so that 
non-technical staff may install the client application. The instructions for 
installation may include directions for requesting network connections, and 
login accounts from application, or network administrators. 

6.111- 13.7 Additional Security Requirements 

The Contractor shall provide the following additional requirements: 

(a) All direct access to clearinghouse system data shall be read-only, except for 
Fare Table updates. 

(b) For the client application, the Agencies shall have the ability to assign access 
privileges to their employees for processing of data downloaded from the 
DACS or clearinghouse system to the local RFCS back-office client 
application. Employees shall not be able to modify fare card data to be 
forwarded from the DACS to the clearinghouse system. 

(c) All query operations, audit control logging, and errors on the client 
application shall be logged in a separate ASCII file or database. 

6.111- 13.8 Documentation Requirements 

13.8.1 Back-Office Client Application 

The following documentation for the back-office client application shall 

be provided. 

(a) Agency Operations Manual 

(b) System Administration and Installation Manual 

(c) User Manual 

13.8.2 Back-Office Integration (Agency-Specific) 

The following documentation shall be provided describing the integration 

at each Agency: 

(a) System Integration Architecture Diagrams and Documentation 

(b) System Installation Procedures 
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(c) System Maintenance Procedures 

(d) System Perfonnance Monitoring Strategy and Procedures 

(e) System Test Plans and Procedures 

(f) Emergency Technical Support Procedures 

(g) Bug-Fix Reporting and Software Service Pack Release Request 
Procedures 


Contract 229944 


6.111-153 


April 29, 2003 





Non-Fare Applications 


Division III 


6.111- 14 Non-Fare Applications (Option) 

6.111- 14.1 Description 

The Agencies have identified the following non-fare application (CDRL 40) to be 
included as an option in the Regional Fare Coordination System. The Contractor shall 
also consider future incorporation of the Non-Fare Application described in Section 

6.III-16.8. 


The Contractor shall include the following Non-Fare Application: 

(a) A Parking Revenue Collection System (PRCS) for Pierce Transit, to be 

installed at the Tacoma Dome Station Parking Garage. Detailed requirements 
for the PRCS will be provided at the time of Option execution. 

6.111- 14.2 General Requirements 

(a) All non-fare applications shall utilize RFCS smart card technology. 

(b) Non-fare applications shall not impact the functionality of the transportation 
application. 

(c) Non-fare applications shall not impact the performance of the transportation 
application. 

(d) Non-fare applications shall be extensible to other sites, other similar 
applications, and other agencies. 

6.111- 14.3 Parking Revenue Collection System 

14.3.1 Functional Requirements 

(a) The Contractor shall provide the following parking revenue 
collection system card configuration options on a single card: 

i. Parking revenue collection system application only. 

ii. Parking revenue collection system application and RFCS 
transportation application. 

(b) The parking revenue collection central equipment shall be 
expandable to include the future addition of other parking 
facilities. 

(c) The parking revenue collection system shall be extensible to other 
Agencies. 
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6.MI-15 System Expansion and Potential Future Applications 

6.MI-15.1 Description 

The following are examples, provided for background information only, of the types 
of future potential RFCS smart card applications that have been identified to date. 
These specific applications will not be evaluated in the Contractor selection process. 
With these types of applications to consider, the Contractor should describe in 
general tenns the characteristics of its system architecture, card design and operating 
policies which would allow for additional non-RFCS applications to the RFCS card. 
The system proposed will be evaluated and scored based on its capability to expand 
and incorporate future, additional applications. 

15.1.1 King County Access Identification and Access 

This includes integrating the RFCS card with existing building 
identification and access systems for a number of current and future King 
County building and garage facilities. Estimated card and reader quantities 
and technical information on existing identification and security systems 
is contained in Appendix C. 

15.1.2 Car Sharing Program 

Car sharing, a program to be co-sponsored by King County Metro, the 
City of Seattle, and the University of Washington would provide access to 
automobiles without the costs and hassles of auto ownership. 

Car sharing is similar to typical car rental services; however, vehicles are 
parked within walking distance of home or work and billing is based on an 
hourly rate, rather than a daily rate. Reservations are made by phone or on 
the Internet and fees are based on time and miles driven. There is typically 
an initial refundable deposit to subscribe to the service. All insurance is 
included in the mileage and hourly rates. For more detail on how the 
program works, see the King County Metro website: 

http://transit.metrokc.gov/tops/oto/carshare.htmI 

King County Metro and Kitsap Transit are also interested in a car sharing 
type program focused on the ferry commuter. Vehicles might be placed 
near ferry terminals that would be available to people who have taken the 
ferry. These vehicles might be part of a HOV commute trip or might be 
available for emergency service when a regular transit service is not 
available. The smart card would be used to access these vehicles and track 
usage. 
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15.1.3 City of Seattle “City Card” 

The City of Seattle is considering the development of a “city card” based 
on European models where citizens have a card to access various city 
services and benefits and pay utility bills, parking tickets, parking meters, 
pet licenses, garbage stickers, etc. as well as link to regional transit 
systems, monorail, car sharing, and guaranteed ride home services. 
Additionally, in return for performing community service Seattle residents 
may get benefits such as purchase of discounted tickets at publicly- 
subsidized facilities like the aquarium and the zoo, discounted purchases 
at stores, credit on City utility bills, et al. The Seattle Smart Card would be 
available only to Seattle residents, providing an attractive transportation 
and civic benefit for people who live in Seattle. 

15.1.4 Transit Oriented Development - Fare Incentives and Secured 
Access 

King County plans to use smart card technology to provide transit pricing 
incentives for residents at Transit Oriented Development (TOD) sites, and 
for secure parking and building access at these sites. In January, 1998, 
King County launched a new TOD program to create opportunities for 
new multi-family housing and related development near bus transit 
facilities in its urban centers. The two (2) primary goals of this program 
are to increase bus ridership and to achieve a greater jobs/housing balance 
in the region by creating communities where public transportation use is 
convenient. 

King County is currently undertaking six (6) pilot projects for this 
program. Downtown Renton and Redmond Overlake are under 
construction, and developer selection/construction is pending on the 
Northgate, Olson-Myers park and ride and the Doces (downtown Seattle) 
sites. A new pedestrian bridge has been constructed just south of King 
Street Station connecting the north Kingdome lot and Pioneer Square to 
existing Metro bus and future Sound Transit commuter-rail and light-rail 
stops. Further development of the north Kingdome lot is expected in the 
future. 

For more information, go to: 
http://www.metrokc.gov/kcdot/alts/tod/index.htm 

6.111-15.2 King County Identification and Building Access 

15.2.1 Functional Requirements 

(a) The Contractor shall provide an identification and building access 
system for the following King County building and garage 
facilities: 
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i. The Regional Justice Center located in Kent, Washington. 

ii. The King County Correction Facility in 2001/2002. 

iii. Buildings within the General Government building system 
including (at present): the Courthouse, Administration 
Building, Garage, Yesler Building, and remote sites; 
Ryerson Transit Base, Issaquah District Court, Department 
of Youth Services, Alder Complex, and the King County 
Sheriffs MARR Impound Lot. 

iv. King Street Facility. 

v. The Black River Building located in Kent, Washington. 

Infonnation on the equipment at these facilities is contained in 
Appendix C. 

(b) The Contractor shall supply fare cards compatible with the existing 
identification and building access system. The existing system 
utilizes Motorola Indala AC 132 26 bit cards. The total estimated 
number of cards is 20,000. 

(c) In the event the proposed fare card is not compatible with the 
existing systems, the Contractor shall supply the cards, readers and 
all other systems and equipment required for the identification and 
building access system. The total estimated number of readers (not 
including spares) is 400. Equipment information can be obtained 
from the manufacturer’s Internet web sites as listed in Appendix C. 

(d) The identification and building access system shall use site codes 
and card /employee numbers as provided by King County. 

(e) The identification and building access card shall be inter-operable 
across all facilities, subject to individual access permission. 

(f) The Contractor shall provide the following identification and 
building access card configuration options on a single card: 

i. Identification and building access application only. 

ii. Identification and building access application and RFCS 
transportation application. 

(g) The Contractor shall be responsible for integrating new equipment 
and services with existing central monitoring, control, network 
management, and reporting systems. 

(h) New equipment and services shall be compatible with existing 
communications and electrical supply. 
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(i) Cards issued for identification and building access shall be dye 
sublimation compatible with the existing systems. 

15.2.2 Performance Requirements 

(a) New equipment and systems shall not impact the performance of 
existing central monitoring, control, network management and 
reporting systems. 

(b) New equipment and systems shall meet or exceed all current data 
storage and processing performance measures. 

6.111-15.3 Car Sharing Program 

15.3.1 General Requirements 

RFCS cards could be used to perform the following functions of the car 
sharing service: 

15.3.1.1 Access to Vehicles 

The card would act as the subscriber’s ID card. The on-board access 
control system would recognize the user as the correct subscriber and 
allow access into the vehicle. Subscribers gain access to the vehicle by 
holding their card next to an access device located on the front dash of the 
car. 

15.3.1.2 Access to the Lock Box and Ignition Key, or Vehicle Based Security 
System 

The card, in conjunction with a PIN number, would allow access into a 
lock box that may be installed inside the vehicle or located close to the 
vehicle. The vehicle ignition key would be stored inside the lock box. 
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The card, in conjunction with a PIN number, would allow on board 
security ignition system to start vehicle for approved driver. 

15.3.1.3 Record Keeping for Billing 

Card access to the lock box would also act as a record keeping function 
for customer billing. Billing, which is based on mileage and hours used, 
could be handled in two ways. Fees could be deducted from the value 
stored on the card, or fees could be billed to a subscriber’s credit card 
account. 

15.3.1.4 Reservations by Phone 

Cards would be used for reservations over the phone wherever the phone 
is properly equipped for such use. 

15.3.1.5 Gasoline and Car Wash Purchases by Subscribers 

Gasoline and car washes purchased by the subscribers will be reimbursed 
by the car sharing organization since these costs are included in the 
mileage and hour usage fees. Subscribers would use their card to access 
gasoline and car wash services; however, these expenses would be billed 
to the car sharing organization. 

15.3.1.6 Access to Secured Parking Garages 

The card would allow access to secured parking garages for after hours 
access to vehicles. The access may be through the building security 
system or through an interface unit that translates authorization to the 
security system. 

6.111-15.4 City of Seattle “City Card” 

15.4.1 General Requirements 

RFCS cards could be used to perform the following “City Card” functions: 

15.4.1.1 Community Service Component 

Volunteer and community work would be rewarded at a set rate (e.g. 

$ 10/hr.) The City would distribute Microsoft Access database compatible 
software to non-profit agencies where the volunteer work was perfonned. 
The agencies would send the information (by e-mail if the database isn’t 
larger than 2 megabytes) with number of hours worked and amount of 
credit earned to the central processing system. Smart card readers and 
sales points would be installed at each Neighborhood Service Center (i.e., 
a storefront office with personnel to conduct City business and address 
citizen inquiries). When citizens use their smart cards at Neighborhood 
Service Centers to pay bills, their smart card would be credited for the 
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volunteer hours. Smart card readers may also be installed at the Zoo, 
Seattle Center, or the Aquarium and with participating merchants to pay 
all or a portion of entrance fees and/or goods and services purchased. 
Funds would be provided to the clearinghouse by the City (raised from 
foundations and private sources, or from fees paid by merchants or banks) 
to subsidize this program. 

15.4.1.2 Linkage with the Regional Fare Coordination System 

The City would coordinate system design and procurement with King 
County and the Regional Fare Coordination contractor to tailor the Seattle 
Card to be compatible. The Seattle Card would have additional functions 
unique to the City, which would be negotiated with the RFC system 
contractor. 

15.4.1.3 Potential Linkage with Merchants and Long Distance Telephone 
Systems 

The New York Chase/Citibank pilot, which enlisted 650 merchants, may 
be a model for this part of the Seattle project. Restaurants, department 
stores, Laundromats, vending machines and taxicabs are potential card 
acceptors. Each business would have a smart card reader. Some might 
even be replenishment stations to add more value to the cards. 

15.4.1.4 Potential Linkage with the Washington State Electronic Benefits 
Transfer System Project 

The State, through the Department of Social and Health Services (DSHS) 
is a member of a seven state consortium developing a magnetic stripe 
Electronic Benefit Transfer (EBT) system through Citibank which will 
begin to go on-line next year. DSHS feels that within five (5) years there 
may be a conversion to smart card technology. At this time, most food 
stores that accept food stamps have debit and credit card reader equipment 
that can be reprogrammed to accept the new EBT Card. The Seattle Smart 
Card might initially contain both a chip and a magnetic stripe contact 
interface to link with the EBT Project. Eventually, the State might adopt 
the Seattle Smart Card system as the next generation EBT card with 
potential savings in time and research and development costs. 

6.111-15.5 Transit Oriented Development - Fare Incentives and Secured 
Access 

RFCS cards would be used to provide fare incentives and secured access for 
participants in the six (6) Transit Oriented Development pilot projects, and for future 
expansion of the TOD concept. 
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6.111- 16 WSF Implementation Requirements 

6.111- 16.1 Description 

Washington State Ferries (WSF) intends to replace its existing revenue and traffic 
data systems starting in 2004 or 2005. Implementation in the WSF environment will 
include installation of electronic fare collection equipment in conjunction with this 
revenue and traffic data systems replacement. This Section outlines WSF specific 
requirements for RFCS equipment to be implemented in coordination with the 
revenue and traffic data systems replacement. 

6.111- 16.2 Commercial Account Program 

The Commercial Account Program is operated by Washington State Ferries to 
provide a post service payment mechanism to commercial account customers for the 
transportation of vehicles and staff on WSF ferry services. Commercial account 
customers include private organizations, as well as government, academic and other 
public institutions. Each Commercial Account has a unique identification number, 
which is used to check that the trip is charged to a valid account. 

Commercial Account customers are billed for actual trips taken at the normal full-fare 
cost. Frequency of use discounts are provided for certain fare types as described in 
the WSF Tariff. 

In addition to the Common Institutional Program Requirements described in Section 
6.II-2.2.1, the Contractor shall meet the following Commercial Account Program 
requirements: 

(a) The Commercial Account fare card shall be initialized with a six digit 
Commercial Account identification number, specific to each commercial 
account customer. All cards issued to the Commercial Account Customer 
shall have the same identification number. This shall be in addition to the 
card-specific unique serial number. 

(b) The Commercial Account payment option shall only be valid for travel on 
WSF services, and shall be valid for all forms of walk-on or vehicle-based 
travel. Transaction information shall be collected at WSF tenninals. 

(c) At the point of use, the RFCS shall confirm that the Commercial Account 
Card and identification number are valid. Invalid cards shall be rejected, and 
the Commercial Account product on the card shall be rejected as payment. 

(d) Fares shall be computed at the time of card use, and adjusted with post-use 
frequency of use discounts, computed and applied per the provisions of the 
WSF Tariff. 

(e) Payment shall be on a post-use billing basis. 
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6.111- 16.3 On-Call Maintenance Service Levels 

In addition to the requirements described in Exhibit 15 Post Warranty On-Site 
Maintenance, the Contractor shall meet the following requirement: 

(a) For remote ferry locations (i.e., Anacortes, San Juans, Port Townsend and 
Keystone), Contractor shall arrive on-site within 4 hours rather then 90 
minutes. 

6.111- 16.4 WSF Implementation Criteria 

In conjunction with replacement of revenue and traffic data systems, WSF has 
identified a two step implementation of the RFCS. As the revenue and traffic data 
systems replacement project proceeds, a decision will be made on whether to 
implement these two steps sequentially or in parallel. 

Step 1: Walk-on Passengers. This includes the implementation of RFCS 
equipment to serve passenger-only routes, and walk-on customers on auto ferry 
routes in the system. 

Step 2: Vehicle Stream. This includes the implementation of RFCS equipment at 
all vehicle toll booths. 

6.111- 16.5 Data Collection System 

In addition to the Data Collection System requirements described in Section 6.III-12, 
Data Collection System, the Contractor shall meet the following requirement: 

(a) The Contractor shall provide appropriate environmental enclosures for the 

DACs that will be located at WSF terminals. Space restrictions will need to be 
accommodated at each tenninal. 

6.111- 16.6 Data Exchange and Back Office Integration 

Washington State Ferries is in the process of replacing its existing Point of Sale 
(POS) system with a new Electronic Fare System (EFS). The Contractor shall meet 
the following requirements for the integration of RFCS equipment with the EFS: 

(a) All records shall be of transaction-level detail and will be used by the EFS to 
process transactions and generate reports. Transaction-level data will also be 
transferred to other WSF and Washington State Department of Transportation 
systems. An example of transaction level data recorded by the current POS 
system is included in Appendix B-6. 

(b) The RFCS shall provide three interfaces to the EFS as illustrated in Figure 
III-16.1. The final architecture of the EFS and associated interfaces will be 
determined at Preliminary Design Review (CDRL 2). Interfaces shall include: 
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i. A direct interface between GAKs installed at WSF toll booths and 
seller point of sale terminal. The point of sale terminal will 
determine the fare to be deducted (fare basis). The GAKs shall act 
as a peripheral to, and be under the operational control of, the point 
of sale terminal. The GAK shall deduct fares based on a fare basis 
message from the point of sale terminal, shall generate transaction 
detail and acknowledgment messages for the point of sale terminal, 
and shall forward transaction data to the RFCS. 

ii. An interface between data acquisition computers installed at WSF 
and the EFS to transmit in near real-time fare transactions from 
Portable FTPs. 

iii. An interface between the Back Office Computer and EFS for back 
office data integration as described in Section 6.Ill-13. 

Figure 111-16.1 

WSF INTERFACES (To be finalized at PDR) 



(c) The Contractor shall provide an Interface Control Document (DR 110.16) 
fully describing these interfaces. This information will be provided to the 
RCS system developer. 

(d) For direct communications between the FTP and clearinghouse, a transparent 
path will be provided for batch data transfer through the RCS. The Contractor 
shall define requirements for such data transfer in DR 110.16. 

(e) Completion of the detailed interface design (Protocol modification required to 
be made to the baseline communications protocol as supplied) will be 
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provided as a separate document from DR112 by ERG during the period 
leading up to FDR submission of DR112b. The documents will describe the 
inter-device communication mechanism between the ERG GAK and a WSF 
POS, and the inter-device communication mechanism between the ERG GAK 
and a WSF gate. The physical communication method and protocol will be 
described in detail. 

(f) The Contractor shall design and build a WSF Gate and POS simulator that 
will enable the WSF GAK development, integration and testing to be 
completed. The simulator shall be built in two steps: 

1. Step 1 - a simple command line simulator for developer use. 

2. Step 2 - a graphical user interface (GUI) simulator for integration and test 
engineer use that will enable integrator and testers to run the GAK in the 
integration and test bed, both in Perth and Seattle. 

3. Instruction manual / user guide. 

6.111-16.7 Food and Sundry Payment System (Option) 

In addition to the Non-Fare Applications described in Section 6.Ill-14, the Contractor 
shall provide a Food and Sundry Payment System meeting the following 
requirements: 

(a) The Contractor shall provide a food and sundry payment system on 
Washington State Ferries vessels (CDRL 40). 

(b) The food and sundry payment system shall be used for purchases from the on¬ 
board concessionaire. 

(c) The Contractor shall supply all equipment and facilities required for the food 
and sundry payment system including as a minimum: 

i. Card reading equipment co-located with all existing cash registers. 

ii. Communications/data transfer system. 

iii. Data management systems. 

(d) The Contractor shall make all arrangements with the on-board concessionaire 
to support the food and sundry payment system including as a minimum: 

i. Installation, operation and maintenance of equipment. 

ii. Revenue management. 

iii. Revenue reporting. 

(e) The system shall provide functionality to block/unblock the food and sundry 
payment application at the discretion of the cardholder. 
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(f) Transaction time for food and sundry purchases shall be a maximum of three 
(3) seconds. 

(g) Customers shall not be required to enter a personal identification number or 
other infonnation for purchases. 

6.111- 17 Gate Adaption Kits 

6.111- 17.1 Subsystem Description - Gate Adaption Kits 


Gate Adaption Kits (GAK) (DR112) shall be devices installed in Washington State 
Ferries (WSF) tollbooths and turnstiles. GAKs shall be designed for wall mounting 
of the GAK in tollbooths, mounting in turnstiles and remote mounting of the card 
reader. 

a) The Kiosk GAK (DR 112) shall be designed for integration as a peripheral to a 
new Point of Sale (POS) system being developed by WSF and shall include an 
interface for integration with the WSF Electronic Fare System (EFS) as a fare 
card payment-processing device. 

b) The GATE GAK (DR 112) shall be designed for integration with Turnstiles that 
are a component of the new POS system being developed by WSF and shall 
include an interface for integration with the new WSF EFS as a fare card 
payment-processing device. 


At a minimum, the GAKs shall consist of the modules listed in Figure 1-17.1 

Figure I -17.1 

GAK CONFIGURATION SUMMARY 


Modules 

GAK 

Central Processing Unit 

X 

Contact less Card Interface 

X 

Card Reader 

X 

Power Supply Requirements 

X 

Communications with DAC and WSF revenue system 

X 


6.111-17.2 Functional Requirements - Gate Adaption Kits 

The following functional requirements supplement those stated in Section 6.III-3.2. 

(k) All Operational control of the GAK will be from the WSF EFS system 
via the Gate Controller (Inside the Gate) for the Gate and from the 
Point of Sale device for the POS. 
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(I) The GAK supplied for WSF shall be able to conduct fare transactions 
as follows: 

i. Automatically with no toll booth seller interaction when a card 
is presented and a default fare deducted or pass recorded. 

ii. Through manual fare determination from WSF POS system. 
In this case, the fare will be computed by the WSF POS 
system, with the GAK acting as a payment acceptance 
peripheral. Valid pass products shall be recognized and 
applied to the cost of the fare. The remaining fare shall be 
deducted from stored value. 

6.111-17.3 Physical Requirements - Gate Adaption Kits 


17.3.1 Structural Features 

(d) The GAK mounts shall be designed for installation inside 
WSF tollbooths and turnstiles. 


6.111-17.4 Data Exchange Requirements - Gate Adaption Kits 

(g) GAKs shall include a communications module for connecting to a DAC. 

(h) GAKs shall include a standard serial interface, designed for connection to 
WSF POS system. The Contractor shall provide an Interface Control 
Document (DR 112) fully describing this interface. 


6.111-17.5 Installation Requirements - GAK 

(a) GAKs shall be designed to be installed on the tollbooth interior wall or 
inside a turnstile. 

(b) The Contractor shall provide the Contract Administrator and WSF with the 
bolt pattern mounting requirements and electrical/communications 
construction and connection details. 

(c) Conduit and power and communications cables leading from the power 
and communications sources to the junction box shall be installed by the 
WSF. Connections from the junction box to the GAK shall be the 
responsibility of the Contractor. 

(d) Contractor shall make final connections (plug-in) to power and 
communications. 

(e) WSF will provide the turnstiles with cut outs for card readers and mounting 
studs for the GAK. 
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(f) WSF will provide a weatherproof electrical box at the exterior of the 
vehicle tollbooths for mounting of the card readers connected to the GAK 
installed in the interior of the tollbooths. 
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